Is there any way of getting current user's password in Windows 10?

Yes, all of that in your article should still work on Windows 10.  Here is another great resource on using Mimikatz that I have found helpful: https://adsecurity.org/?page_id=1821.

One note though, Windows 10 Enterprise has the availability of Credential Guard.  If the system is running Enterprise version and has Credential Guard enabled, the hashes are not currently accessible to the best of my knowledge.

Plain text? Simply, in Windows 10, no.  In Windows 7, WDigest is still enabled by default so passwords ARE horrifically cached in plain text.  In Windows 10, that is gone by default.  Ref: https://blogs.technet.microsoft.com/kfalde/2014/11/01/kb2871997-and-wdigest-part-1/


Of course any password that is stored in plain text is a bad idea but the location of the file is in /etc/my.cnf so if a remote user had access to that file I think there would be more things to worry about than having your mysql password stolen. On the other hand if you are not the only one who has physical access to the system then you are still safe from others reading your file since your file permissions are 400, assuming no one escalated privileges on the system. I did some research about having your password in my.cnf file and it's true it's actually a pretty common practice.

By the way you need to make sure you don't actually edit the file thats located in the /etc/my.cnf which mysql server uses to boot up because if you do anyone can use the server with ALL privileges and ALL databases without a password. So instead create a file in your local /root directory call it my.cnf and make sure only root can read it (of course)

The easiest way to do this is to use a client section of the ~/.my.cnf file, and add the credentials inside that file.

[client]
user=root
password=somepassword

Like I said make sure the file is ONLY readable by root. –


IPsec (Internet Protocol Security)  facts

IPsec is actually a family of protocols, it has several sub-protocols that could be used or not used, and the overall security depends on each of these in turn and how they're configured:

IKE for protocol negotiation and key management
AH for authentication, integrity and I think some protocol protection
ESP for encryption and then some.

Advantages:

Transparent to applications and users (in most scenarios). To emphasize, this is not a trivial point - I have had many times when my recommendations to clients would be to encrypt the channel, e.g. with SSL - however they dont have access to source code, or SSL is not supported by vendor, etc - and IPsec is basically drop-in encryption (as far as the app is concerned) and totally out of view of the app.
Very secure, if implemented correctly
Less prone to user mistakes (as SSL)
More efficient than SSL, if you're encrypting most of the traffic anyway

Disadvantages:

Can be complex to deploy, depending on your network and requirements
Cannot be used over Internet or with unknown clients (okay not strictly accurate, but still holds for most intents and purposes).
Can provide false sense of security to network admins, if deployed incorrectly (e.g. without ESP, but hey I've got IPsec, right?).
Much less efficient than e.g. SSL, if you don't need to encrypt all the traffic (but IPsec will do so anyway).


If hashing is one way, why can we decrypt MD5 hashes?

Hashing is not encryption (it is hashing), so we do not "decrypt" MD5 hashes, since they were not "encrypted" in the first place.

Hashing is one-way, but deterministic: hash twice the same value, and you get twice the same output. So cracking a MD5 hash is about trying potential inputs (passwords) until a match is found. It works well when the input is "a password which a human user came up with" because human users are awfully unimaginative when it comes to choosing passwords.


"Cannot contact any realm 'KERBEROS.TEST' while getting initial credentials"

Your client needs to contact a KDC for the KERBEROS.TEST relam.  It was either unable to find a KDC, or unable to contact a KDC.

To find what you're doing wrong, you'll need to investigate and eliminate various scenarios.

Do you have a config file (/etc/krb5.conf) that names the realm?
Can your client find the domain name of the KDC ?

The client could find KDCs in the [realms] section of the krb5.conf
The client could find KDCs through DNS using SRV records.

Can the client connect to the KDC ?

If your client knows the realm, the problem is probably in step #2 or step #3.

If you are using MIT Kerberos, here are links to documentation that may help:

Realm configuration decisions including naming and finding KDCs.
MIT Kerberos clients support a KRB5_TRACE variable which could let you get more details about the internal details:

KRB5_TRACE=/tmp/tracefile.txt kinit, and then inspect the tracefile.


Will browser isolation solution protect our enterprise from Flash and JavaScript exploits and fileless malware?

This will add another line of defense which will provide a better (but not perfect) protection against some attacks but not against others. It will probably be mostly effective against an attacker trying to break out of the browser into the system, although sandbox techniques used in modern browsers like Chrome already provide a good (but not perfect) protection in these cases.

But it will not help against Javascript-based or Flash-based attacks in general, i.e. it will not help against Cross-Site-Scripting or CSRF or cross-site flash attacks. These are not attacks which try to break out of the browser but instead work inside the browser and thus also inside the isolated browser.  A properly isolated browser might though prevent these attacks to affect your internal network. Browser isolation will also not help against social attacks like phishing for credentials.


How to Verify Integrity of Transferred Files in a Client Server Protocol

Your process is not OK. How can you make sure checksum is transferred correctly or hasn't been tampered with along the way?
You need some sort of authentication before transferring file, a handshake! All this can be solved using SSL. You will not have to worry about anything.


Why are OSX users of my TLS-only site being asked to supply a client certificate?

An SSL client will use a client certificate only if duly requested by the server. If both Chrome and Safari claim that the server requests a client certificate, then this probably means that the server indeed requests a client certificate. As was pointed out by @Ben, it is quite possible that the server requests certificates for everybody, but most non-OSX users don't have certificates at all and their browser silently answers to the server that they don't have any certificate.

To be sure that a certificate is indeed requested by the server, run Wireshark. You should be able to see the SSL handshake details, in particular the CertificateRequest handshake message from the server. You will also want to check that the server who requests a client certificate is indeed yours: verify that the Certificate message from the server contains the exact certificate that you configured on your server.

In any case, since the SSL handshake contains checksums which are computed over all exchanged handshake messages, a CertificateRequest message cannot be smuggled into your handshakes without breaking the procedure (client and/or server will complain loudly).

Unfortunately, the two suggested scenarios don't ultimately work:

If there is some load balancer misconfiguration which redirects some clients to another server, that other server should not have a certificate matching your site name. Client browsers should flash their scary warning popups. On the other hand, if the other server actually has a certificate with your site name in it, then this is an attack, and a very successful one; it would make little sense for the attacker to blow his own cover by stupidly asking for client certificates.
If the problem is a misconfiguration on your own server (e.g. a .htaccess file which overrides your SSLVerifyClient setting), then the problem should not be intermittent. For a given URL, it should always happen, or never.

My best guess (not a good guess, but the best I can offer) is that your site embeds some advertisements from a third-party ad provider, and some of these ads point to a misconfigured SSL-powered server. This would explain the "intermittent" part: you get the certificate popup on the random occasion where the ad provider points you at that specific misconfigured server. Trace analysis with Wireshark would reveal that, by the way: if you find a SSL handshake with a CertificateRequest message, then the corresponding Certificate message will contain the offending server's certificate, and the server's name (and you should also find it as part of the Server Name Indication extension in the ClientHello message). So go install Wireshark and see for yourself.

(On Windows, Microsoft's Network Monitor would work equally well.)


Legitimate use case of man-in-the-middle attack for DPI?

This is possible technically to achieve but there are some problems with it.  In response to your questions

Some would agree with you that this is a legitimate use of MITM. There are already popular products in the corporate world that implement this approache (e.g. BlueCoat)
The least friction way of doing this would be to get signing cert signed by a known Certificate Authority, and then create legitimate certs as needed.  Unfortunately unless you're the government that's not a likely option.  The standard way to approach this is as you say, get users to install your certificate authority into each device in use.  I don't think browser add-ons would work
I'm not aware of a way of doing this without installing additional software, which would in effect be the same level of effort as installing your cert, so not a lot of point really.
Yep Certificate pinning will cause problems with this and is becoming more common as time goes by.  The way this works is that the browser knows of a specific certificate or set of certificates that it trusts for a given hostname, and it won't base that trust on certificates being issued by a known CA.  I'm not aware of a way past that problem.
I've done a little reading on that proposal and from what I understand of it I'm not a fan.

Another problem for you to think about with the kind of product that you're looking at is, how do you handle invalid certificates when your device encounters them?  Say for the sake of argument your proxy makes a connection to a site and it has an invalid certificate.  Do you

a) issue a certificate to the user that's valid (e.g. signed by your device CA).  At this point what if that site is a phishing site and you've just stopped the user from identifying that the certificate was invalid which could have alerted them to the problem?

b) issue a deliberately invalid certificate from your CA, so that they can see the problem.  Most users (assuming that they're savvy enough to look at certs) will then just assume it's a problem with your device.

c) pass the connection straight through so that the user can make a correct determination that they could be connecting to a malicious site?  At this point that becomes a known way to bypass your device and you also lose the ability to protect the user from malicious content on that site.

or

d) Block access to any sites with certificate errors.  This is probably the best way to solve the problem but still leaves you with a customer perception issue "we installed this thing and it broke access to our site"


How does Kerberos protect against replay attacks?

Kerberos uses an 'authenticator' during protocol exchanges that occur between the client and the server. It holds additional authentication data, such as the ticket lifetime, and most important, the client's timestamp.

  When Server-Side Kerberos validates an authentication message, it will
  check the authenticator's timestamp. If the timestamp is earlier or
  the same as a previous authenticators received within the five minutes, it will reject the packet
  because it treats it as a replay attack and user
  authentication will fail.

Server-side Kerberos additionally compares the timestamp in the authenticator to the server time. If the timestamp in the authenticator isn't within five minutes of the time on the server, it will also reject the packet.

The five minutes is the maximum difference it can tolerate between client and server, but you can change this value in windows through group policy.

In a nutshell, the crucial part is the 'authenticator' time validation.


Authenticating services with PKI (pycrypto)

First, you don't pass private keys to another service. In general, a key should be considered compromised if it is ever passed to another service. If you want to totally trust the authentication microservice, then just use passwords for authentication. You can generate them in a secure manner manner avoid weak passwords.

The right way to authenticate with asymmetric encryption is to use a challenge-response model. In this, the authentication service would generate a random number, encrypt it using the client's public key, and then pass the encrypted value to the client. By responding with the clear-text secret, the client proves that they have the private key corresponding to the public key in the database. So the messages would basically be:

Client-->Server: Authenticate Alice
Server-->Client: Decrypt encrypt(text, Alice's public key)
Client-->Server: text in clear-text
Server-->Client: Here's your token...

Probably the best way to do this is to use mutual-authentication TLS. That manages the challenge/response within the network stack. By the time the microservice is called, you will already know that the user holds the private key. You can just return the token at that point. The messages would be:

Client-->Server: Give me the token for Alice
Server-->Client: Here's your token...

The first step, where the TLS handshake takes place, will involve multiple on-the-wire messages, but that will be handled automatically.


The exact signature scheme depends on the protocol version; however, in all cases, it relates to what Crypto++ calls "signature schemes with appendix".

PKCS#1 describes two signature schemes (and two asymmetric encryption schemes, which are not relevant here): the "old one" (called "v1.5") and the "new one" (called "PSS"). SSL/TLS relies on the old one (v1.5).

In PKCS#1 v1.5 signature generation, the following occurs:

The data which is to be signed is hashed, with some hash function. Let's call x the resulting sequence of bytes. E.g., if the hash function is SHA-256, then the length of x is 256 bits, i.e. 32 bytes.
A header t is added to x. The header is a fixed sequence of bytes that identifies the hash function (technically, x is used as parameter in a DER-encoded ASN.1 structure that also identifies the hash function with an OID; however, it is simpler to think of it as a fixed header).
Some bytes are added before the concatenation of t and x, so as to obtain the following structure:

   00 01 FF FF ... FF 00 t x

That is, a byte of value 0, then a byte of value 1, then some bytes of value FF, then a byte of value 0, then t, then x, are concatenated in that order. The number of "FF" bytes is adjusted so that the total length is exactly the length, in bytes, of the RSA modulus (i.e. 256 bytes for a 2048-bit RSA key). This step is called "PKCS#1 type 1 padding".
The padded string is then interpreted as a big integer (using big-endian convention), which then goes into the modular exponentiation that is at the core of the RSA signature scheme.

With TLS-1.2, the signature scheme must be exactly the one above, with a hash function that depends on what the client and server support. With the Signature Algorithms extension, the client specifies in its ClientHello message what kinds of hash functions it can use with the RSA algorithm; if that extension is lacking then the server must assume that the client supports SHA-1. The value of the t header is given explicitly, for the most common hash function, in section 9.2 of PKCS#1.

In previous TLS versions (SSL-3.0, TLS-1.0 and TLS-1.1), the scheme is subtly different: the t header is empty, and x is the concatenation of the MD5 and the SHA-1 hashes of what is to be signed. Thus, the length of t is 0, and the length of x is 36 bytes (16 bytes for the MD5, 20 bytes for the SHA-1). There is no discussion between client and server about which hash functions to use; it is always MD5+SHA-1.

A cursory look at the manual seems to indicate that at least "normal" signatures (for TLS-1.2) can be computed with Crypto++ using RSASS<PKCS1v15, H> where H will be SHA1, SHA256... I do not know if Crypto++ includes code for the older scheme where the hash is the concatenation of MD5 and SHA-1, and there is no header.


Why use Linux instead of Windows for Pentesting?

Overall, this question is rather broad, and will likely have an issue with opinions obscuring facts, so I'll try to keep this answer purely-factual.

say e.g. am using aircrack in windows what will be my disadvantage ?

We can answer that right from the developers of Aircrack:
From Tutorial: Getting Started:

This tutorial is focused on linux. Yes, I realize that linux is a problem for many people. Unfortunately Microsoft Windows simply does a poor job supporting the aircrack-ng suite. This is primarily due to the proprietary nature of the operating system and wireless card drivers. See Tutorial: Aircrack-ng Suite under Windows for Dummies for more details. Bottom line, don't use the aircrack-ng suite under Windows. There is little or no support for it.

And from Tutorial: Aircrack-ng Suite under Windows for Dummies:

First and foremost, Windows is virtually useless for wireless activities due to the huge number of restrictions. The restrictions do not come from the aircrack-ng suite so please don't ask for enhancements.
Here is a quick recap of the limitations:

Very few supported wireless cards: There are very few wireless cards which will work with the aircrack-ng suite. Most laptops come with Intel-based cards and none of these are supported. See the following links: Compatibility, Drivers, Which Card to Purchase and Tutorial: Is My Wireless Card Compatible? for more information. It is also important to note that there is little or no documentation accurately describing which version of the third party drivers you require for each card.

Dependency on third parties: The Windows world is highly proprietary and thus the source code for the drivers is not available publicly. As a result, no troubleshooting or fixes are available from the aircrack-ng team for these third party drivers. If there is a problem, you are on your own.

Limited operating system support: The Windows version works best with WinXP. It does not support Win98, some people have reported success with Win2000 but many have been unsuccessful with it and Vista is not supported. There is some evidence that a few people have aircrack-ng working under Vista but most people report failures. So basically, your best chance of success is under WinXP.

Passive capture of packets: Most people want to test the WEP security on their own access point. In order to do this, you must capture in the order of 250,000 to 2,000,000 WEP data packets. This is a lot of packets. With Windows, you can only capture packets passively. Meaning, you just sit back and wait for the packets to arrive. There is no way to speed things up like in the linux version. In the end, it could take you days, weeks, months or forever to capture sufficient packets to crack a WEP key.

Limited GUI: Most of the aircrack-ng suite tools are oriented towards command line utilization. There is only a very limited GUI available to assist you. So you must be more technically literate to successfully use these tools. Thus, if you are used to running a Windows installer then clicking your way to happiness, you are going to be exceedingly unhappy and lost with aircrack-ng.

Technical Orientation: Dealing with wireless requires a fair amount of operating system, basic wireless and networking knowledge. If you don't have this or are not prepared to do your own research, then you will find the tools and techniques bewildering. Do not expect people on the forums or IRC to answer basic knowledge questions. It is up to you to have these skills before starting out.

If you truly want to explore the world of wireless then you need to make the commitment to learn and use linux plus the aircrack-ng suite linux version. An easy way to start is to utilize the Backtrack live distribution. This distribution has the aircrack-ng suite plus patched drivers already installed which jumpstarts your learning process. BackTrack information can be found here.

So as a quick overview, the developers of Aircrack state that support for Windows is very limited, not because they haven't developed full support, but because the platform itself limits what they can do.


How to defend against network traffic pattern correlation attacks?

What if you used a network like tor but one that has a more difficult algorithm that connects to each host within the farm?

'Network traffic pattern correlation attacks'. I heard that such an attack was done to trace users in Tor network by the Russian government.

I think if someone executes such an attack against you, then it is a matter of proxy servers you use between you and the destination host that you try to connect to.

The 40mb file that was downloaded in one host at specific time, could be attempted to be traced back, but it depends on how many proxies you use.
The more of them, the more investigations the authorities will have to make to trace you.

To even go farther, you could use a proxy server that modifies the content of the request slightly and adds content to it at random length.


Does HSTS protect against a rogue CA issuing a illegitimate valid certificate?

No, HSTS does not protect against certificate misissuance. HSTS simply tells the browser to only allow connecting to that site over HTTPS, it doesn't have anything to do with checking whether the certificate should be trusted.

There are two things that can help with misissuance to some extent, Certificate Transparency (CT) and Certificate Authority Authorization (CAA).

Certificate Transparency won't prevent misissuance by a CA, but it requires that certificates are publicly logged, so you can check and see if any certificates have been issued for your domain that shouldn't have been. Since 2018 Google Chrome has required that all new certificates issued be CT logged in order to be trusted. Firefox does not yet unfortunately, but in practice all certificates issued these days are CT logged as otherwise they would not work with Chrome.

Certificate Authority Authorization allows you to indicate which CAs are allowed to issue certificates for your domain using a DNS record. This will prevent accidental issuance by a CA, but of course a bad actor will just ignore it. Since CAA is only intended to say which CAs are allowed to issue a certificate at a specific point in time, and not for the lifetime of the certificate (ie if the CAA record changes the certificate is still valid), this is only a useful control for CAs that aren't bad actors, as it can help prevent them from issuing a certificate they shouldn't have which could eventually lead to their being distrusted. In fact, the RFC specifically requires that browsers not check CAA records.

A third option is HPKP, which allows you to pin a specific certificate that must be used for your domain (it needn't be a leaf certificate, pinning your CA's root would be somewhat similar to using CAA, but more effective), but it has fallen out of favor and is no longer supported by Chrome.

EDIT: curiousguy points out an interesting attack to work around CT logging in some cases. If an attacker has a Man in the Middle position, they may be able to tell which browser is establishing a connection early on (eg due to minor behavioral differences in the TLS stack). This could allow them to decide not to attack connections from browsers known to check CT logs, simply forwarding the connection to the legitimate server, but present a misissued and non-CT logged certificate to other browsers in order to impersonate the legitimate server. It seems that the only way to prevent this would be for all browsers to check CT logs.


When and why does bypassing XSS sanitizers with double encoding work?

Lets look at this example payload (A), encoded once (B) and twice (C):

A. <script> alert(1) </script>
B. %3Cscript%3E alert(1) %3C%2Fscript%3E
C. %253Cscript%253E alert(1) %253C%252Fscript%253E

Double encoding can be used to bypass XSS filters when different parts of the applicaition makes different assumptions about if a variable is encoded or not. For instance consider the following vulnerable code:

$input = htmlentities($_GET["query"]);
echo urldecode($input);

This code would block the payload if it was just single encoded (as in B). PHP URL decodes your GET variables for you by default (turning B into A), so < and > would be passed to htmlentities that  neutralizes them. However, if you instead send in C, it would be URL decoded to B that would pass through htmlentities unchanged. Since it is URL decoded again before it is echoed, it turns into the dangerous payload A.

So the bug here is that there is another layer of URL decoding after the XSS filter. When the two lines are next to each other like this, the problem is quite obvious. But these two things can be in separate modules making it hard to detect. Since it's hard to keep track of what strings are URL encoded, it is tempting to just throw in an extra decoding to be sure - after all, it usually doesn't affect unencoded data.

The PHP manual actually warns about this:

  Warning: The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results.

In my opinion the manual is not cautious enough here - decoding any untrusted data after filtering for XSS is dangerous, no matter where it comes from. Be extremely careful with modifying your data after you have filtered it!

For more reading, see OWASP.


PHP bin2hex vulnerable to timing attack?

In what scenarios would bin2hex be vulnerable to a timing attack?

The timing attack discussed in the mailing list and blog post is a cache-timing attack, which was famously demonstrated by Daniel J. Bernstein against OpenSSL's implementation of AES here (PDF).

In order for bin2hex() to be vulnerable to a timing attack, the following conditions must be met:

Internally, it either indexes or branches based on the secret we are trying to protect (e.g. HMAC key). The PHP implementation does index based on what could potentially be a secret.
The attacker has to be able to alter the state of the processor cache somehow. (e.g. Renting a neighbor VM on the same baremetal machine with your cloud provider and executing a strategy similar to FLUSH+RELOAD.)
The attacker can rapidly issue many valid requests from a privileged network position with minimal network jitter (surprisingly trivial these days).
The key we want to protect is reused. (General case; some CSRF tokens are not reused.)

The feasibility of such an attack is still an unknown, but patching this potential side-channel is actually not that difficult. The previously linked methods were derived from libsodium's bin2hex implementation, which was provided by CodesInChaos.

Is this below code for handling a CSRF token vulnerable to a timing attack?

I don't know. The bin2hex() might be a very minor concern, but not one that I can demonstrate a practical exploit for. Maybe someone in Crypto Stack Exchange can?

Update: There's a Lib for That

If you use paragonie/constant_time_encoding (which didn't exist when you asked this question), you shouldn't leak any information via cache timing.

<?php
use \ParagonIE\ConstantTime\Hex;

$rawBinary = random_bytes(32);
$data = Hex::encode($rawBinary);
$decoded = Hex::decode($data);

This library cover all of the RFC 4648 encoding schemes:

Hex
Base32
Base32Hex
Base64
Base64UrlSafe
Base64DotSlash
Base64DotSlashOrdered

The latter two are compatible with crypt(3).


How can a user defend against session hijacking?

Here are some suggestions. None of this will give you the same level of security as TLS would, though.

Don't use the site unless you really have to. But since you ask, I assume you do.
If you visit it, use a VPN (or Tor) as often as possible. An attacker would have to get in the middle of your VPN exit and the server in question, which is harder than getting in the middle of you and the server (but not impossible, especially not for a governmnet - or the provider of the VPN/Tor exit node...).
If you don't use a VPN, at least don't use it over Wi-Fi. That is so much easier to sniff than a cable network.
Stay logged in for as short periods of time as possible, and always logg out when you are done. Don't check the "remember me" box.
Unless the login page is over HTTPS, you should be more worried about your password then your session ID... If the login page is over HTTPS, always check that you have a secure connection so you don't become a victim of SSL-strip.

Depending on how likely you think it is that you will be the target of an attack this may or may not be enough. I am afraid there is not much else you can do.


Cloud-based IM protocols / services saving messages encrypted on server which is decryptable only by user?

This part worries me:

Server send the public key of B to A.

Chatting:

A send the message encrypted with A and B's public key RESPECTIVELY to
the server. (i.e. send the same message twice, encrypted with
different keys)

This tells me that A at one point received B's public key, and that to send a message the client needs to have both public keys. If A has B's public key this could allow an impersonation attack where A establishes a chat session with C.
I'm fairly confident the service has more layers of security but from this extract that that you posted here that would be one concern for me.


I have registered a .com domain and received an e-mail from domainadmin.com

As Polynomial mentioned, this is part of ICANN-mandated WHOIS verification. The reason it goes to domainadmin.com is that ICANN doesn't actually run the verification -- rather, like just about all ICANN things, they set policies that are then implemented by others (remember, your .com domain is in a registry operated by Verisign, and was registered by a registrar who was neither ICANN nor Verisign). It's the registrar's job to verify certain WHOIS info; the relevant policy is here, and they must suspend your domain if they can't verify the info.

The reason you're seeing domainadmin.com is that whoever you bought your domain from is likely reselling them from OpenSRS (which basically exists as a platform for domain resellers), which is a label of Tucows. As the registrar, Tucows is responsible for WHOIS verification on domains bought from them; because OpenSRS is mostly a platform for resellers, they generally do so via domainadmin.com (which they own, and which is intentionally white-label). Source 1, and a discussion on their site about this domain choice.

So, this email is likely legitimate, and you need to do what it says or your domain will be suspended. domainadmin.com isn't affiliated with ICANN, it's affiliated with your registrar (you actually bought your domain from a reseller of this registrar). It's intentionally generic because some resellers want a generic thing; resellers who want non-generic have the option to make it non-generic, but most resellers don't want it showing OpenSRS or Tucows prominently.


You usually set up a host name for DDOS protection by having a DNS CNAME record that points to the DDOS protection provider. This lets the provider adjust the IP address (or addresses) that the domain points to.

Setting up www.domain.com to use a CNAME record is easy. It's not so easy for domain.com because once a host name has a CNAME record, it cannot have any other records, and domain.com would usually have MX and NS records to handle mail and DNS resolution.

However, CloudFlare now supports CNAME flattening which does allow this.


Examples of hacking causing serious destruction or death

All from DEFCON from the past:

Cesar Cerrudo on hacking traffic lights

Barnaby Jack also had a talk scheduled on hacking pacemakers, but he died before he ever spoke IIRC.


Is there a security threat to a Windows XP computer only being used as an analogue fax server?

Despite this XP machine is not directly accessible from the Internet and there might not be attack vectors through the analogue fax machines, being on the same LAN makes it a good target for lateral movement and gaining persistence on your network.

I'd put this XP machine on a separate VLAN and isolate it as much as possible i.e. only allow the mandatory access for this legacy functionality. That could be e.g.

deny access from the machine to the Internet.

this must be done on network level, as once someone is already inside he can modify the settings on the local machine

deny access from the machine to the LAN

there's no harm to assume it could be compromised

allow limited access from the LAN to the machine

only the ports absolutely required
IDS/IPS on the traffic, if possible
if someone gets limited access to any of the LAN computers, he could use this to gain full access on this vulnerable XP.


Disabling TLS protocol in protocol level or in cipher list level: What's the difference?

The confusion comes from the way OpenSSL words its configuration options.

In the protocol, there are two very distinct things:

The protocol version. This can be SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2 (or something else, not yet defined). Internally, the version is encoded as a 16-bit integer of value 0x0300, 0x0301, 0x0302 or 0x0303, respectively (so TLS 1.0 really is "SSL 3.1" on the wire). (I am not talking about SSL 2.0 here.)
The cipher suites. These are (on the wire) 16-bit identifiers for the combinations of cryptographic algorithms that the client and server are willing to use. The client sends a list, the server chooses the one which will be used. Most cipher suites work for SSL 3.0, TLS 1.0 and TLS 1.1; a few recent cipher suites work only with TLS 1.2 because they use protocol features that are available only with TLS 1.2.

OpenSSL uses, in its configuration string for specifying a list of cipher suite, some mnemonics such as "SSLv3". In that context, "SSLv3" does not mean "protocol version 0x0300"; it means "the list of cipher suites that can work with SSLv3". When you write "!SSLv3" in the configuration for the list of supported cipher suites, you should read it as "remove all cipher suites that could possibly work with SSL 3.0". But this is NOT: "remove all cipher suites that could possibly work with SSL 3.0 when actually using SSL 3.0". The removal is all-or-nothing; you do not get to remove support conditionally on the protocol version (that would be conceptually feasible, but OpenSSL does not work like that).

So if you remove support for all cipher suites that could possibly work with SSL 3.0, you are also removing the cipher suites for ulterior protocol versions. In particular, since SSL 3.0, TLS 1.0 and TLS 1.1 all use the same cipher suites, the only remaining cipher suites in your list are the ones that are specific to TLS 1.2. In effect, you have just killed TLS 1.0 and 1.1 support as well.

If you use "!SSLv3:!SSLv2" then the server can pretend to still support SSL 2.0, but with an empty list of supported cipher suites, so it won't go far; an actual handshake won't happen. It is like giving the key for your car but removing the wheels.


PCI DSS for web servers not storing credit card info

The requirement is that each server have a primary function rather than a single function. You can argue that the primary function of the server is as a web server and the database functionality is a secondary function. Consider a Domain Controller which can be a DHCP server, NTP server, DNS server, authentication server, security policy server.

In terms of security levels for PCI compliance, given that the database is not storing cardholder data, there is no requirement for this to be a separate server on an internal network segment. As the server itself is in scope, everything on the server is in scope so the database still needs to be hardened and logging so you're still securing the system and mitigating risk.

If you have a QSA, s/he should be able to provide guidance.


How to know an SMTP server is securely configured

There are free services that test for remote relay availability (just google for smtp relay test to turn up several) which are going to do the same thing attackers do (attempt to relay mail, watch the result, report back).  If you perform a few of these, get their results and can match it up with your log file (to identify why the relay did/didn't work) you can pretty easily tell if you are going to unleash a spam zombie or not, and what other config issues there might be.  Postfix has a lot of configuration options, but is pretty mature so they have streamlined basic setup (believe it or not) vs what it was 15 years ago.


The Girl in the Spider's Web: SCSI hack?

SCSI cables would not be used to carry video signal, but ribbon cables would be used to connect controllers. Given the few details you provide, it would be more likely that a controller was added to change where the video signals from all those CAT6 cables ended up.

Can you vampire tap a SCSI cable to duplicate a video signal? No. You would be more likely to sever all those little wires. Vampire taps need to be used on thick cables to ensure the integrity of the cable.

So, yes, plugging in ribbon cables looks all old-school techy (just like mounting keyboards vertically on walls). And a nice flat 34-strand ribbon cable makes a nice visual for clipping something on to. But in reality, it would have been more realistic to interact with the CAT6 cables that are actually carrying video signal.


Can schools track what I'm doing, even though I'm on my personal Gmail account?

No. They would have access to the stuff you do on your school account. They can't access everything just through their access to your school account.
There are other ways for them to see what you do on the computer if they have things installed on it.


How safe is to leave a open port on router without anything listening to it?

You should check out this question including the accepted answer:

A port isn't open if something isn't listening for a connection on it.
The reason it is bad form to have all ports open to everywhere is that it exposes those services that are listening on those ports to exploits. That is why firewalls exist, to limit what is allowed to connect to certain ports, to reduce the surface area exposed by services.

To answer your question: There is no risk in opening ports if no services are listening on the port.


How to save a web page with its certificate?

Saving the certificate won't help you.

When the HTTPS connection that delivered the HTML page was opened, your browser and their server securely established a (random) session key to use for the rest of the TLS session. Before proceeding with the HTTP request, your browser also verified that it was indeed talking to the owner of the certificate that was presented (that is, the holder of the corresponding private key).

When the HTTPS connection was closed, that session key was discarded (by both ends), so even if you had saved the ciphertext of the HTTPS interaction, neither party could decrypt it a second time. But anyway, neither of you saved the ciphertext unless you happened to be capturing packets at the time.

In short, your browser claims that the document displayed in its window is an untampered version of exactly what was delivered by the server but it is not in possession of what it takes to prove that.


Should I go for Master of Science by GIAC SANS and what to do with my expiring GSEC cert?

There are better certs than gsec (CCIE, CCSP, CISSP to name a few), if you really want a useful cert I would explore those.  Posting a question and asking for more responses to your previous question (see: spamming) is not a good way to endear yourself to knowledgeable experts on this site.  You might want to think about not asking 5 part questions as well, your initial title is referencing pursuing your Masters but you also ask about certs.

I don't think your own startup should count as sec experience, and if you're thinking about getting a Masters you might want to start by doing a lot more research in the security field first.  That program is for experienced professionals, and from the questions you asked in your prior question it seems as if you don't possess any knowledge beyond the most basic of security principles.  There is a reason they have the work qualification, because if you don't have experience you will probably be over your head.  If you're truly interested in security, I would recommend thinking about not how you can get around the admission requirements and obtain some "degree", but how you can actually improve and broaden your security related knowledge.


eIDAS - list of certified qualified electronic signature creation devices


encrypted cloud storage with partial local copy

While not a direct answer to your question, my personal suggestion would be to use a standard file hosting service that meets your needs and perform your own client side encryption and decryption.  This is really the only way you can know for sure that the service provider doesn't have any way to be able to access your data.  This opens up the door for you to be able to have much more control of the security of your data while also being able to use a much broader set of service providers to find one that meets your needs overall.


The speech input API specification doesn't mention how it should be implemented. But in the requirements section there is a bullet point about encrypting communications with remote speech servers[1], it's a not a requirement for now.
As for Chrome, it seems to be using a remote speech to text server using a POST over https according to this article[2], note this it's about Chrome 11 and it might have changed in the recent release.

http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html#requirements_section
http://mikepultz.com/2011/03/accessing-google-speech-api-chrome-11/


1.3.6.1.4.1.77.1.2.25 is only one OID (Object ID, or some people call it 'MIB value') you can use to extract some information from an enumerable SNMP service. OIDView keeps a comprehensive list of more than 7000 MIB values from more than 500 vendors.

My personal favorites for Microsoft Windows are

1.3.6.1.2.1.25.4.2.1.2 gives you a list of all running processes on the machine. Very handy to figure out the possibility of, say, future escalation vulnerability if a specific application is running.
1.3.6.1.2.1.25.6.3.1.2 gives you a list of installed software and Windows hotfixes & updates. Very useful to probe for missing patches in, say, IE. Now you can send a link to a specific exploit to the user of that machine via email.
1.3.6.1.2.1.25.6.3.1.5 gives you a list of when those patches were installed. Very nice to know how often the system is maintained. Gives you ideas on how to proceed with your post-exploitation.
1.3.6.1.4.1.311.1.13 gives you entries in the vent log. Very good to trace crashes in certain applications.

and the list goes on and on, and not just for Microsoft Windows, but also for hundreds of other products.


First off, "input validation" is when you say "the input needs to match a certain format" and reject otherwise, like:
if !is_phone_number($input) {
   return400();
}

What you are showing is not input validation, it's output escaping. Specifically php's htmlspecialchars() is making the data safe to output directly into an HTML document.

I feel like you're missing the second half of your code how you are using this input. To be HTML XSS you have to inject this input into an HTML context (which you have escaped for, so that probably won't work, assuming php's htmlspecialchars() is done properly), or inject it directly into a javascript context, or a Kendo template, or something.
To be SQLi you have to use it to construct an SQL statement.

If you want to make this vulnerable to XSS, but in a subtle way, I would do the following:
Set the ENT_NOQUOTES option to htmlspecialchars() so that single and double quotes are left un-encoded.
Then use this input directly in a javascript blob, for example return this HTML page:

Nothing to see here...

Now, because you have excluded quote and double-quote un-escaped, the following input:
";alert(1)

will result in your server rendering and serving the following html:

which will pop the alert box (or whatever other javascript payload you put in).


Is combining salt from two places secure enough and what length

That second part of the salt you are talking about actually has its own name - it's called a pepper. And as long as the real salt itself is always unique for each password, adding a pepper doesn't decrease security in any way (it arguably increases it in some scenarios).
Regarding the length of the salt, 16 random bytes* each will be more than enough. Since 16 random bytes is 128 bits of entropy, you can be sure there is practically no chance of your salt ever repeating for more than one password.

*Note that 16 random bytes means 16 random bytes of binary data, not a 16 character string. See Steffen Ullrich's comment


When do Ps Tools send cleartext passwords, and how can I demonstrate this?

I believe most of the answers you seek are in the analysis by Mike Pilkington presented at SANS Forensics and IR Summit – June, 2011:

Blog posts:
http://www.dshield.org/diary.html?storyid=11173 and
http://computer-forensics.sans.org/blog/2010/06/01/protecting-admin-passwords-remote-response-forensics/

PDF of presentation slides:
http://securityscaper.com/Protecting%20Privileged%20Domain%20Accounts%20during%20Live%20Response%20-%20June%202011.pdf

The blog posts and presentation discuss the technologies in detail, explain his investigative methodology, and recommend safer ways to use the tools.

The general theme is to use alternate authentication methods to avoid exposing passwords to the network but with care taken so these accounts are insulated from compromise by malware on the suspect system.

In the DFIR blog post above Mike says:
"First, there is an easy workaround you can employ with PsExec to avoid sending your password in clear text. The trick is to first mount the IPC$ share of the remote computer and then use PsExec. Jean-Baptiste Marchand has written an excellent article about this technique, as well as several other remote administration tips." linking to an detailed article by JBM from 2005:
http://www.governmentsecurity.org/forum/topic/28152-windows-built-in-remote-administration-tools/

hth,
adric


What is the opaque field in HTTP Digest Access Authentication used for?

If you drill into the An Extension to HTTP : Digest Access Authentication RFC, they define opaque as follows:

  opaque:
        A string of data, specified by the server, which should be
        returned by the client unchanged.  It is recommended that this
        string be base64 or hexadecimal data.  This field is a
        "quoted-string" as specified in section 2.2 of the HTTP/1.1
        specification.

which is pretty close to what you saw in the RFC you mentioned, further in the get into details a little more

  The opaque data is useful for transporting state information around.
  For example, a server could be responsible for authenticating content
  which actually sits on another server.  The first 401 response would
  include a domain field which includes the URI on the second server,
  and the opaque field for specifying state information.  The client
  will retry the request, at which time the server may respond with a
  301/302 redirection, pointing to the URI on the second server.  The
  client will follow the redirection, and pass the same Authorization
  header, including the  data which the second server may
  require.


Is it good or bad practice to allow a user to change their username?

Many people have looked at the reasons not to allow name changes from both a security and a community standpoint. However, there are plenty of legitimate reasons to allow username changes, even if the username is separate from the display name, for example:

Someone has changed their real life name or the name by which they'd prefer to be called, due to marriage, family situations, escaping stalking/harassment/etc., and so on

  Even in the case of it being simply a username, having to use an old name which carries trauma can further the trauma. Also, it is quite possible for a stalker/harasser to know their target's login credentials, and being able to change both parts of the credential lowers the attack surface; further, monitoring attempts at logging in to an abandoned username allows for building a legal case against a bad agent.

People have decided to move forward on a gender transition

  Being forced to use one's "dead name," even in the context of a private username, is also very traumatic. (I can speak to personal experience on this one.)

People have a username that they no longer feel suits them for whatever reason

  This has less of an implication for internal usernames but it's still better to err on the side of kindness, in my opinion.

These are all important for user comfort, and in many cases people would likely just create a new account with the new name anyway, so might as well support it.

Avoiding social engineering certainly is important but there are approaches that help to mitigate this, such as various forms of verification (as seen on several social networks), public-key cryptography, and profile indicators ("name last changed N months ago; name changed K times"). And, since this question has been edited to be regarding internal user names and not public display names, those concerns aren't even germane to the discussion.

Also, keep in mind that many attack surfaces provided by someone changing their username is also present for someone simply creating a new account, and if a username change option is not available then the user will likely create a new account - possibly using the same password as the old one and otherwise doing things that might lead to compromised security.

It is a good idea to maintain an audit trail of username changes and disallow the creation of new accounts that use a previously-used username (at least if the username was last used within the past, say, year), but there is no reason that the username should ever be the primary key used to associate data with the user account in the first place, because there are legitimate purposes for a username change and all account records should be normalized to an abstract internal-only ID in the first place.


How does password reset work if 2FA is enabled?

Technically, this is a question about how you should implement 2FA (or how you should expect it to be implemented), since there's nothing inherent in 2FA that answers your questions in either direction. With that said, there are certainly best practices.

2FA (or multi-factor authentication in general) should apply whenever the user is being asked to prove their identity in any way (that is, to authenticate). So you should prompt for MFA when the user is doing anything where you would normally request a password (such as changing their current password or email address, or changing MFA settings). You should also prompt for MFA any time the user is doing anything that takes the place of a password, such as clicking a link in a password reset email.

For your three scenarios, #1 is unlikely just because requesting a password reset email usually doesn't require any authentication at all, so it'd be an odd place to put a MFA demand. However, using the email in any way - that is, actually resetting the password - should require MFA. So #2 is technically incorrect - an attacker can't reset the password - but it's true that they can't log in either. The correct answer is sort of "#1.5".

However, again, "which one actually happens" will depend 100% entirely on how that particular service implemented MFA, and there's no guarantee they've done it correctly. I've seen sites that do it like #3.


How can I bypass double quotes in a attribute based xss attack

The encode() method HTML encodes characters, which is the correct XSS prevention method in this context.

So if a " character was inserted inside of $str to try and break out of the HTML attribute context, this would be converted to &quot; or &#34; which is the HTML representation.

Therefore it is not possible to inject script here, assuming encode does not have any flaws itself that allows this to happen.


If some people have put some hidden backdoors in your system, and if they were competent at it, then you won't be able to find them. "Competence", here, means "having an Internet access and typing 'rootkit mac os x' in Google". See e.g. this. It is theoretically impossible to completely hide a backdoor, but only in the same sense that it is theoretically possible to write software without any bug. In other words, it is hard.

"Security labs", whoever they may be, can try to see in your machine if they find something fishy. Possibly, if you observe strange symptoms, they might be able to explain them without postulating a virus / backdoor / malware. If you do not want to show them your computer, then, no escape: you'll have to do the analysis yourself, which means acquiring a few years of technical skills.

Alternatively, reformat the hard disk, then reinstall from scratch. Very few malware can survive that.


Is it ever safe to install patches in parallel on a Windows OS? When must I reboot after each patch?

The phrasing your question is very confusing. "Is it ever safe to install patches in parallel on a Windows OS?". Yes, sometimes it's safe. Is it always safe and is it easy to know those 'sometimes'? No.

In the Windows Registry, there's a sub-key called PendingFileRenameOperations. It handles situations where certain operations are performed on files while being locked and performs them when the files are released, and, more specifically, after a reboot. Windows Update installations (including security fixes independently installed security bulletins) make extensive use of this feature in order to apply those patches/fixes. "What could go wrong?", you ask. Well, let's see this example:

You installed Security Fix #1 which contains (amongst other things) File_A version 0.3 which should replace your locked File_A version 0.1, the operation is added to the Pending File Rename queue (mentioned earlier).
Without a reboot, you installed Security Fix #2 which contains (amongst other things) File_A version 0.2 (vulnerable), because your file is locked, the operation is added to the queue (remember, at this point, before the reboot, you still have version 0.1 of that file).
After you reboot, the queued operations are executed on your file in their respective order. File_A is first replaced with version 0.3 and then replaced with version 0.2 (vulnerable).

Had you rebooted between those two fixes, installer would have been able to check the version of the actual file on disk and prevent version 0.3 from being replaced by version 0.2. Since the file on disk is actually 0.1, the installer had no concerns.

Microsoft has a neat little tool called Qfecheck which goes through the installed security fixes and updates and makes sure that they're properly installed and no such situation has occurred. When used in a big environment in batch, it's very useful for generating automatic reports on the patch status of all computers in a corporation.

But wait, there's more! Microsoft also has another very neat tool called QChain. It makes sure that you always have the latest version of the file in the pending operations queue. Here's how to use it:

Run your updates with the -z switch to prevent reboot.
Run QChain.exe
Reboot.

That's it!


What is the meaning of this TLS output: TLSv1.2 (OUT), TLS alert, Client hello (1)

Although it's related to HTTPS = TLS, I'm not sure this is really a security question. OTOH I don't know how to migrate and am not sure where would be better.

  What is the meaning of TLSv1.2 (OUT), TLS alert, Client hello (1) after the connection is closed, is it trying to reconnect?

It's not after closing, it is part of closing, i.e. it is after initiating close. Specifically, the TLS client stack sends an alert record with level=1 (warning) in the first byte and description=0 (close_notify) in the second byte; this is a normal part of a client-initiated TLS close. The callback curl uses to log protocol actions (when requested with -v) lamely decodes all records as handshake records (even though here it correctly identifies the record as an alert record) so it misdecodes the first byte as a handshake message type (1=Client Hello).

  Is it being sent by the server, or by the client? If by the client then is it being sent by openssl or curl?

It is sent by the client (curl is the client and OUT is sending). It is sent by the TLS stack used by curl, which isn't always OpenSSL, although it may be here. Unless you know for sure e.g. because you built it yourself, you can check with curl -V (uppercase vee) which stack your build of curl uses.

  I have seen some curl outputs which don't have the string and Closing connection 0 is the last output, what does that mean?

curl should always log 'Closing connection' if you have specified -v (and not otherwise). It may not log the 'OUT ... alert ... 1' if either it is using a stack without the callback (which AFAIK could be anything other than OpenSSL) OR the server has closed quickly enough (like, immediately) after the end of data so that the client stack doesn't need to and can't notify the server -- or even before the end of data, but that should give an error indicating the data is incomplete. And of course even when curl does issue these outputs, it writes to stderr which in most environments can be redirected or discarded.


How safe are Firefox addons from official mozilla.org site?

The accepted answer is out of date.
As of October 28, 2017 Firefox FAQ states a different view (note the "may"):

Are add-ons safe to install?
Use caution when installing add-ons, as they could harm your computer or violate your privacy.  Add-ons available from this site may be subject to review by Mozilla's team
of reviewers, and user feedback is closely monitored, so they should
generally be safe to install.


What could you do with a PTR record of "localhost"?

An attacker could try to bypass a hostname-based whitelist on your server.

In a naive scenario, you might configure SSH or a firewall to only allow connections from "localhost", intending to lock out all remote machines for security reasons.

A smart SSH server would recognize that 113.175.205.167 is remote and block the connection attempt. Eventually, it would resolve localhost to 127.0.0.1 and see that the IPs don't match.

However, a server with a flawed implementation might first conduct a reverse DNS lookup of the IP, find the localhost entry, and reason that the hostnames match, thus allowing the connection.

NB: Resolving localhost to 127.0.0.1 is obviously done internally in most cases, skipping the DNS query (e.g. by looking it up in /etc/hosts). Hence, a malicious DNS server cannot easily attack the other way round by resolving localhost to an arbitrary IP.

Why does that particular IP resolve to localhost?

Here, it's likely not part of an attack, but because that IP is located in Hanoi and apparently, "The Country of Vietnam Resolves to Localhost". The reason seems to be an outdated technique to bypass e-mail spam filters.


Google: log in on a new machine without a phone

I think this is a misunderstanding on your part of the importance of this additional security measure.

Might I introduce you to this site: https://haveibeenpwned.com/

This website, run by a Mr. Troy Hunt, keeps track of major data breaches and provides a service to see if you've ever been a part of one. If you had an account on a site that might be insecure (ie, Yahoo) and shared the same password on yahoo with Google then a hacker could effectively have your password.

Your password is effectively an authorization measure that grants access based on "something you know". More specifically, it's supposed to be "something that only you know".

If someone could steal your password from one of these data breaches or by any other means then you lose that ability to identify yourself. By requiring your phone to log in (in cases where the request came from a new device or new location) you can help protect the account of those who might've have their password stolen.

The phone is "something you have" which means that in addition to gaining knowledge (your password) that you're supposed to only have, they have to have physical access to something that only you should have (your phone).

Oftentimes, security measures end up detracting from user experience. Obviously there are cases where you won't be able to access your phone and it can be stressful. Google does offer an "offline" solution to this. You can set up "Backup Codes" for your Google account. When you set this up, it'll create a little notecard pdf (that you're supposed to print out and carry in your wallet/purse/etc) with 10 separate, 1-time-use codes on it that you can use whenever you need to log in with two factor.

Here's where you can go to set it up. Go to https://myaccount.google.com/security. After that, select 2-Step Verification.

I would enable two step verification so you can use backup codes in place of this phone-based verification. Additionally, enable two step verification on other services as well.


Can APK's installed from unknown sources without special permission be considered safe?

An app that maliciously exploits some system vulnerability may be extremely dangerous, and does not need "suspicious" permissions.

Apps that you download from the official Play Store undergo some (undocumented) verification process which includes anti-virus scan, but most importantly are banned as soon as some malicious activity is detected by Google or other organizations that specialize in monitoring such threats. This does not mean that you can be sure that an app that you install from Play Store will do no harm, but the risk is significantly higher outside.

I would recommend to have an anti-virus app if you need a sideloaded app which you cannot trust, and if you can, use such app on a secondary device that does not hold your vital data.

Also, Android is constantly upgraded to fix many vulnerabilities, therefore latest system may be safer. If you can, use the latest system.

Use Google's Verify Apps which is part of the Play Services. It can identify some harmful apps. This means that it is worthwhile to use a device with Google Services installed and up-to-date.


Making a bitcoin-like secure mail protocol, how to tackle public keys?

Now I've got this problem: public keys (currently RSA) are extremely long. When you would want to send a mail to someone, you would need to know their public key.
Are there any asymmetric encryption algorithms that use smaller public keys? Or some way I can put the long RSA key through a RIPEMD160 and it still being usable?

This is a known problem with conventional public key crypto systems, e.g. RSA and DH and among other things one reason why Elliptic Curve Cryptography (ECC) is so appealing. Usual key sizes range from something between 160 to 512 bit, while providing the same level of security.
Another potential way to solve the problem is a scheme similar to the one implemented in DNSSEC. Here you have two key pairs, which are different in length. The shorter one has to be replaced more often (once per month or so), but is the one that actually is doing all of the signatures. Personally I don't like this approach very much, but it was specifically designed in this way to make signatures shorter.


Options when defending against SSLstrip?

Here are my recommendations for what users can to defend themselves against SSLstrip, Firesheep, and similar attacks:

Install HTTPS Everywhere or ForceTLS.  (HTTPS Everywhere is easier to use.)  This tells your browser to use the SSL versions of web sites, where possible.
If the browser gives you a certificate warning, do not bypass the warning, and do not continue browsing that web site.
For critical sites, like online banking, go to the HTTPS (SSL) version of the site from your machine while using a secure network, and then bookmark that page.  Then, always open the site by opening the bookmark whenever you want to go to that page.  Never type its address into the address bar or search bar.
If you will only be browsing a single site, consider configuring a site-specific browser.  This is probably not needed for most purposes, but it will provide additional security against some attacks; it might be appropriate, e.g., for businesses that are using online banking.
Alternatively, instead of HTTPS Everywhere, you can do your web browsing via a VPN service.
Configure your email client to use SSL (also known as TLS) and to check the validity of certificates.  This will ensure the connection to the email server is encrypted.

Here are my recommendations for what web sites can do to protect their users against Firesheep, SSLstrip, and similar attacks:

Enable SSL sitewide (i.e., HTTPS).
Enable HSTS (HTTP Strict Transport Security).
Make sure that your certificate is valid.  Consider buying an Extended Validation (EV) certificate, for more security-critical sites.
Enable secure cookies, i.e., ensure that all cookies are served with the secure attribute, so that your user's browsers will only send those cookies back over SSL-protected connections and never disclose them over any non-SSL (HTTP) link.
Disable HTTP (non-SSL) access, or redirect users to the SSL version of the web site.
Avoid or minimize use of third-party Javascript libraries, widgets, like buttons, etc.  Or, if you must use them, make sure they are served from a https: URL and that the site hosting them is one you trust.

On a different topic, administrators of mail servers can protect their users by enabling SSL/TLS protection for IMAP (or, better yet, requiring use of SSL/TLS on all connections) and by enabling STARTTLS on their SMTP servers.


Enterprise standard for securing servers.

Standards are general and consist of high level principles. Guides focus on practical security. Checklists are the most detailed documents.

There are multiple agencies that produce security standards. One of the most widely used security standards today is ISO/IEC 27002 which started in 1995. This standard consists of three basic parts, BS 7799 part 1, part 2 and 3. Recently this standard has become ISO 27001. But it is a very high level standard that doesn't go into configuration specifics. It talks about building an information security infrastructure (BS 7799 part 1), an information security management system (BS 7799 part 2) and risk analysis and management (BS 7799 part 3).

You are asking about guides and the National Institute of Standards and Technology (NIST) has released several special publications addressing cyber security. Here is the Guide to General Server Security from NIST. This general document discusses the need to secure servers and provides recommendations for selecting, implementing, and maintaining the necessary security controls.

NSA develops and distributes security configuration guides for a wide variety of software, both open source and proprietary.

Applications
Database Servers
Operating Systems
Vulnerability Technical Reports

For more detailed documents about securing certain installations follow NIST's National Checklist Program Repository. NCP security checklists (or benchmarks) provide detailed low level guidance on setting the security configuration of operating systems and applications. For example there are checklists for securing:

Web Servers
Email Servers
Applications Servers
Operating Systems


How are TPMs provisioned for Intel Trusted Execution Environment (TXT)?

The Intel TXT is a complex system designed to provide a hardware layer of security that can prevent software layer changes from resulting in increased access for attackers. Through use of stored hashes of known good states for firmware, bios, and OS loads, TXT can indicate when something has changed outside of a known good state. This is helpful for identifying potential rootkits within an environment.

According to Intel, the use of TXT depends on :

  Intel TXT requires a server
  system with Intel VT, an Intel TXT-enabled
  processor, chipset, ACM, enabled BIOS,
  and an Intel TXT-compatible MLE (OS or
  hypervisor). In addition, Intel TXT requires
  the system to contain a TPM v1.2, as
  defined by the Trusted Computing Group
  (http://www.trustedcomputinggroup.org), and specific software for some
  uses -- https://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution-technology/trusted-execution-technology-security-paper.html

Now, TXT was initially designed for workstation components where only one OS was truly expected to be used at any given time, barring virtual instances within the host (Type 2 hypervisor). This contrasts starkly to servers which may have several hosts attached to the bare metal through a type 1 hypervisor. This required the creation of a more dynamic TXT system which would evaluate the booting OSs as they launched instead of attempting to read all potential hosts at the initial start.

Going beyond the differences between workstation and server, TXT does not work with all operating systems or all OS configurations. As an example, not all versions of Windows 10 permit the use of intel TXT and device guard:

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-device-guard

As it pertains to the how to configure, it does change depending on your hardware, firmware, and OS selection. See the Intel configuration guide:

https://software.intel.com/en-us/blogs/2012/09/25/how-to-enable-an-intel-trusted-execution-technology-capable-server


This is not one of the standard cryptographic hash functions. There is also some sort of encoding which includes things other than the hash, because both strings end with the same sequence '686f736973616'.

In fact it looks to partially be the direct encoding of ASCII strings, possibly truncated. Ignoring the leading 'F' and the final '6' (are you sure the values are not truncated when you display them ?), your examples map to =$'2:  4hosisa and ,'7amorphosisa respectively, which look suspiciously non-random to me.

Looking at it more closely, I notice that this so-called "hash" is just a byte-wise XOR. Namely, it seems to go thus:

Convert the password to lowercase.
Pad the password to 14 characters by appending spaces.
XOR the encoding of the password with the encoding of: metamorphosisa
XOR each resulting byte with 0x20 (the ASCII encoding of a space).
Convert the result into hexadecimal.
Put a 'F' at the beginning and a '6' at the end.

I.e. not a hash at all, rather one of the weakest forms of homemade encryption.


How to check if any host trying to connect back to the my executable(application)?

The quickest and easiest way would be to verify whether there are processes keeping a socket open for listening.

You need a utility such as netstat (Unix, Mac and Windows). There are also GUI utilities - I seem to remember tcpstat and wintcp for Windows. Also Process Explorer by SysInternals and TCPView.

These utilities will provide you with the open ports being used and the process ID of the owning process. You need then to verify whether the process is legit or not, and you can research the port number on Google.

Also, you can run an antivirus/antimalware scan to see whether there are known threats active.

And you can do something quick and dirty such as scanning the system for recently changes files (there will be a lot of those), reviewing the changes to determine whether they're legit or not.

On, say, a Windows system, recently created files with executable extensions (.exe, .scr, .com, .dll, .pif, .lnk, .bat, .cmd, .ps1) are a prime suspect unless you know they're harmless. Files such as .htm, .html and .js outside of browser directory are also untrustworthy (unless you're a Web developer and those are your files). Recently changed files with the same characteristics are also suspicious - a sufficiently advanced virus can easily hide within another executable (and would probably also reset its modification time and date so you don't notice anything, so while a change is suspicious, not detecting any changes is not a guarantee unless you have at least a set of trusted file signatures from beforehand, kept in a trusted place, and a trusted way of checking them, e.g. Tripwire Boot CD or USB key. Some level of defense is usually supplied by the operating system in some ways, e.g. Windows has SFC and Linux has AppArmor, but they're far from a silver bullet).

Finally you can monitor system changes with their date (registry keys, initialisation scripts and tasks).

These are quick, relatively easy, and simple approach and probably won't detect more advanced threats such as rootkits and "stealth" viruses. In that case, there are rootkit-detecting utilities too (both from antivirus companies such as ESET, and well known sources such as Rootkit Revealer or rkhunter).

Still more advanced threats - packages knowing and actively trying to circumvent rootkit detection strategies - do exist, are not as likely as a straight "open socket and lurk" drop-in trojan horse, and would require considerable knowledge to operate.

--

And that's why you don't just download and run 'hacking applications' on a non-disposable machine without knowing exactly what you're doing and/or how to monitor said machine, or are ready to nuke it from orbit afterwards, wiping it clean and reinstalling everything (and even this has a vanishingly small probability - the same of having annoyed NSA, the Mossad or equally easygoing guys - of not being enough. It would have to be a tailored attack, but they do exist).


Can my employer see my phone browsing history on my work desktop?

As mentioned in some comments, this will depend on the setup your employer has on the pc and in the network you are working on. You are in your rights to be concerned about your privacy and we all should always keep an eye in the correct use of personal data even if it's something simple as our search results and youtube video history.

If your gmail accounts are synchronized in the browser, all your synchronized settings will be in all of your devices. If you are just logged in, you will need to access account settings and view history from there. This means that whoever has 'physical' access to a device with your account can see your activity. This does not mean that your employer has access to it even if that info is on the work computer, unless he walks to the computer and uses it.

But there are malicious ways to gain more information or access to your accounts like a remote monitoring tool. If your work pc has a remote tool, then he can get access to the PC remotely and view your stuff since the accounts are already logged in.

Another way can be to have a keylogger installed in the background and everything you type will be recorded by the employer. They can get passwords and other information from you.

Another malicious way is that the network has some type of proxy (mitm) which all network traffic goes through. This way they can get your password, cookies or any other useful stuff. This way they can impersonate you on a different device and gain access to your account.

So if you want to be 100 percent sure you are not being monitored, check all your account settings, your connected devices, check for malicious software and backdoors in the pc... Then use a VPN when you are at work.


The parameter is not correct. As documented:
3.6.7 dsize
The dsize keyword is used to test the __packet payload__ size. This may be used to check for abnormally sized packets that might cause buffer overflows.

Thus, it is about the payload of a packet. It is not about the payload size of a HTTP body, since the body can be spread over multiple packets, it can be or start in the same packet as the HTTP header, it can be compressed ...


Limit access to services. IPtables is a good way to handle that. Setup connect rules that enforce what you described for each service and drop everything else.
Limit your daemons through proper configuration. If you only authenticate with a public key over ssh (and you're confident enough that you won't lose it and deny yourself access), turn off password and keyboard auth. Fail2Ban is handy for brute force attempts, but instant rejection is rather satisfying too. Configure your FTP server to only export the related directory tree.
Assume that each of your daemons is compromised now... except maybe SSH because that's just one of those things. Use external facilities to limit what the daemon can do on your host.

I'm a huge fan of AppArmor on Linux because the configuration is something that can be reasonably understood and it's very powerful for sand-boxing applications. For example, you can limit Postgres and anything ever executed by it to only affect the database storage field. The same applies for web and FTP servers -- they never need to read anything any data that's outside of their operating directories and never need to open another network port. Get an email alert to any violations of those rule sets.

Isolating your services like that will give you confidence in the integrity of the machine as a whole even if an individual service is compromised.


What do I do if I find XSS on my website?

The first step is to patch the vulnerability by escaping any HTML entities or removing any dangerous characters all together.

Reflected XSS is a client-side attack method, caused by a server side vulnerability. I wouldn't worry too much about any damages if you didn't catch an XSS worm in action or actually saw anyone using the exploit to attack other users. Just because you found a vulnerability in your code doesn't necessarily mean it has been exploited.

Most often XSS bugs aren't looked for as quickly as something like SQL injection or server side code executing has a way more devastating impact as it hits the server rather than the client. You could try looking in your web server's logs, or query your database for any strange characters such as < or > which are often required to perform XSS based attacks.

Any other way to prevent stolen cookies from being re-used is by forcing all your users to re-authenticate.


Preventing path traversal knowing only the input

You cannot do this securely. It is a fundamentally broken approach. You need contextual information about the application and the filesystem, which you cannot gain from an external perspective. The best you can do is deploy a WAF such as Apache's mod_security and enable a bunch of path traversal rules to try to block path traversal attempts, but a determined attacker will eventually find a way around those rules.

If someone has given you this task, consider that the first step in any task is to perform a feasibility study. You work out if the task is possible, what the approaches are and what benefits and drawbacks they have, then you do a cost-benefit analysis. In this case the primary cost is risk. I suggest that you go back to whoever gave you that task and explain that you technically can do this, but it's a blacklist approach that isn't ironclad and it will involve standing up some additional infrastructure in front of the web server (and that means maintaining and patching it too, particularly the WAF part!). Then you can leave it to them to weigh those costs up against a more complete solution, such as getting the web application actually fixed.

If the web application in question is made by a third party, report the directory traversal as a security vulnerability. If it's a product or service that they sell, you can use responsible disclosure to push them to fix it if they're slow about it. If the web application is something that your organisation contracted a third party to make for you, you can check the contract to see if they are liable for fixing security vulnerabilities (you should also write this into your contracts!)


Is it possible for someone to figure out my WIFI password by following me?

The situation you describe isn't really a concern. The WPA2 handshake never actually sends your password across; both the access point and the client send derived messages that demonstrate that they know the same password. So, spoofing a WPA2 access point won't help recover the password. However, it is possible to record the messages involved in a successful authentication between your client and the access point, and then attempt to brute force it offline, so it's important to have a strong password (or really, passphrase).


Does it work? IPS and IDS are very specific configurations. Plus, the general behavior of each provider is different. Some fail-open, some fail-closed and some just fail.

The best way to audit is to:

Identify what assets/resources are being protected by the ((IP|ID)S).
Document the current configurations. (You need to know exactly what polices are being applied to each protected asset/resource). Literally, map asset/resources to policy.
Determine what tools and test need to be run against the assets/resources.
Run the sets and interpret the results.
Tune the device as needed.
Realize that you will get false(neg|positive)results.
Realize that the application is the right place to fix vulnerabilities.
Repeat 3-7 until confidence rating is high or completely shot.
If confidence rating is completely shot or you don't want to have all this weight on your shoulders and massive ramp up, get experts on the problem.


Hardened SSL ciphers for Nginx as AWS/Cloudfront Custom Origin

As of today (August 2013), known weaknesses of MD5 have no impact whatsoever on the security of SSL/TLS. Issues with MD5 may induce problems with X.509 certificates, but this is a CA business and is unrelated to your choice of cipher suites.

In that respect, RC4 is actually weaker than MD5. RC4 induces measurable biases, which very rarely have any importance, but at least are real.

If I understand your problem correctly, Cloudfront will connect to your server as a SSL client; then, it suffices to run on your server a network monitor tool (e.g. Wireshark) to capture a connection attempt from Cloudfront's machine; the first SSL message from that machine, the ClientHello, will list the protocol versions and cipher suites that the Cloudfront machine supports. If you want to know what your server actually supports (i.e. the effect of your configuration), try this tool, or that one if your server can be contacted "from the Internet". Compare the lists, find what is missing.


Given the step P = ras_encrypt(Bob's public key, K + S), there isn't really a way for Alice to deny that she knew K, and therefore knew (or could have known) the content of M, and therefore she can't plausibly deny that she sent the message M to Bob. Some other person who does know K could create H, and Alice could have been duped into creating S from H.  However, the step that generates P requires Alice to know K, so she can't plausibly deny being able to read M', which for all practical purposes means she knows what was in M and therefore sent M to Bob (and he has proof that she did so).

However, we can consider a variation on the proposed protocol which would mean that Bob knows Alice forwarded the message, but does not prove that Alice knew the content of the message that she forwarded.  The alternative solution, using any appropriate public key cryptosystem (PKCS), is:

Alice picks a random key K, and encrypts the message M using this key K.
    M' = AES(K, M)
Alice hashes K and Bob's public key.
    H = SHA(K + Bob's Public Key)
Alice encrypts K (plus arbitrary extra material if the key is deemed too short) using Bob's public key:
    K' = PKCS(Bob's public key, K)
Alice encrypts H using her private key.
    S = PKCS(Alice's private key, H)
Alice encrypts K' and S using Bob's public key.
    P = PKCS(Bob's public key, K' + S)
Alice sends P, M' to Bob.

When Bob receives P, M', he:

Uses his private key to decrypt P and get K', S.
Uses Alice's public key to decrypt S and get H.
Uses his private key to decrypt K' and get K.
Uses his public key and K to validate H.
Uses K to decrypt M' and get M.

Alice can now deny creating the message because she could have been duped by Mallory (the malicious) into taking M', H, and K' and producing S and then P, and sending P and M' to Bob, without actually knowing K or what's in M.  It would require some gullibility to have been deceived like that, but deniability may require the appearance of gullibility.

If Eve (the eavesdropper) intercepts P and M', she can do nothing. She cannot decrypt P because she does not have Bob's private key. Therefore, she cannot retrieve K' or S, and therefore cannot get the original K or M.

Clearly SHA and AES can be any agreed upon secure hash algorithm and symmetric (private) key algorithm.

Or have I goofed somewhere?


Is it safe to include memory addresses in a program’s output?

Purely from a programming point of view, instead of using an objects memory address to link these two pieces of data, you really should be generating an index number and using that to refer between the structure and your annotation.

I can't see any reason why it would be dangerous though to include the addresses in the report, since as soon as your program terminates the address space is freed by the OS.  While it may not be zeroed out (data may remain in memory until overwritten), you probably aren't at risk of exploitation.


Primitive RFID keys can generally be copied easily. (CloneMyKey.com says it can clone 90% of RFID tags.)
In most cases it's just a chip that emits an ID, which can't be changed. But sometimes it can be reprogrammed - and sometimes you can order tags programmed with specific requested IDs. (See YouTube videos for RFID Cloning.)

The card itself doesn't have to be a card, it can be a device, which obviously won't have a burned-in ID, which can be used to replay RF transmissions to mimic the signals normally emitted by a legitimate card. They are just radio waves after all.

Some systems will use a simple ID check from the card to determine if the card has the right ID to allow access.
Some systems (like NFC) do have protection from these replay attacks, with varying degrees of fallibility. The same technology is used in Oyster cards, on the London transport network for example, and there are numerous cases of this technology being hacked, with card skimming and replay attacks taking place and uploaded to YouTube - How to Clone an Oyster Card.

Credit/Debit card NFC payments involves two parts of information being sent from the card to the reader, one request from the reader is to identify the type of card, next the reader makes a request to the card that is specific to the type of card, this effectively unlocks the card, which then transmits the next piece of data, used to confirm the card is legitimate.
The second request the card makes involves using a secret key that is proprietary information, known only those associated with the card industry. The card itself has built in defences to prevent brute force attacks to discover this key.

So yes, it is possible to clone some RFID cards (or tags), and it is possible to impersonate them with devices, but it depends how a specific system is using these devices as to how vulnerable each system is to this style if attack.

Is NFC still a vulnerable technology


Use msfencode: https://www.offensive-security.com/metasploit-unleashed/msfencode/

The 0's you're talking about are null bytes, which are essentially terminators. When ever the program encounters a null byte, the program is terminated. Using msgencode you can use the -b option to avoid the usage of null bytes.

In addition you might want to avoid other characters as well suchs 0x0A and 0x0D which are line breaks.

root@kali:~# msfencode -h

    Usage: /usr/bin/msfencode >options>

OPTIONS:

    -a >opt>  The architecture to encode as
    -b >opt>  The list of characters to avoid: '\x00\xff'
    -c >opt>  The number of times to encode the data
    -d >opt>  Specify the directory in which to look for EXE templates
    -e >opt>  The encoder to use
    -h        Help banner
    -i >opt>  Encode the contents of the supplied file path
    -k        Keep template working; run payload in new thread (use with -x)
    -l        List available encoders
    -m >opt>  Specifies an additional module search path
    -n        Dump encoder information
    -o >opt>  The output file
    -p >opt>  The platform to encode for
    -s >opt>  The maximum size of the encoded data
    -t >opt>  The output format: bash,c,csharp,dw,dword,java,js_be,js_le,num,perl,pl,powershell,ps1,py,python,raw,rb,ruby,sh,vbapplication,vbscript,asp,aspx,aspx-exe,dll,elf,exe,exe-only,exe-service,exe-small,loop-vbs,macho,msi,msi-nouac,psh,psh-net,psh-reflection,vba,vba-exe,vbs,war
    -v        Increase verbosity
    -x >opt>  Specify an alternate executable template


Are PHP magic methods really necessary for PHP object injection?

The statement in that form is false. You can use any method for PHP object injection. The important point is that the method must actually be called.

The advantage of magic methods is that they are all named the same, and __wakeup and __destruct are both automatically called.

In this specific case, rewind works as it's called as part of the iterator in the foreach loop.

But it works also in other simpler examples. Imagine for example that you have two classes, both of which have a method of the same name:

class Foo {
    public function bar() {
        echo "everything is safe here";
    }
    [other methods...]
}

class BadFoo {
    public $command = "something";
    public function bar() {
        echo exec($this->command);
    }
}

Now you want to unserialize an object of the safe Foo class, and call the bar function on it:

$foo = unserialize($_GET['foo']);
$foo->bar();

Obviously, an attacker could simply send an object of the BadFoo class instead, leading to code execution:

O:6:"BadFoo":1:{s:7:"command";s:2:"id";}

This shows that it works with any methods, not just magic methods, as long as the method is called and does something an attacker is interested in.


When authenticating ciphertexts, what should be HMACed?

The MAC is there to detect alteration of the data you are interested in, i.e. the result of the decryption. So you have the following choice:

either you compute HMAC over the plaintext data (i.e. before encryption when encrypting, after decryption when decrypting);
or you compute the HMAC over the encrypted data itself (i.e. after encryption when encrypting, before decryption when decrypting).

In the second case, you have to include in the HMAC input everything that impacts the decryption process, i.e. not only the encryption result per se, but also the IV which was used for that encryption, and, if the overall protocol supports algorithm agility, you should also input the specification of the encryption algorithm (otherwise, an attacker could alter the header of your message to replace the tag which says "AES-256" with the tag which says "AES-128" and you would unknowingly decrypt with the wrong algorithm).

For security, the second choice (encrypt then MAC) is better; see this question on crypto.SE for details (to sum up, when the MAC is computed over the encrypted data, it cannot leak information about the plaintext data, and since it is verified before attempting decryption, it protects against chosen ciphertext attacks). SSL uses MAC-then-encrypt and it has been the source of a lot of issues (all the "padding oracle attacks" and also the so-called BEAST attack would have been avoided with encrypt-then-MAC).

As for the keys, ideally, the encryption key and the MAC key should be derived from a master key with a PRF. In plain words: hash your master key K with SHA-512; the first half of the result will be the encryption key, the second half will be the key for HMAC.

But, really, you should use EAX or GCM. They do everything correctly and (that's an important point) they have very light requirements on IV selection: they just need a non-repeating IV, hence can use a simple counter, whereas handmade CTR needs non-overlapping IV ranges (an IV with uniform random selection is correct, but randomness is a hard requirement)(and CBC is even worse, it needs unpredictable randomness). The only justification for not using EAX or GCM in a new system (where you are not constrained with backward compatibility) is a possibly non-availability of an EAX or GCM implementation. I would argue that, even in this case, it would be better to retrofit some AES-ECB code into an EAX implementation.


You can try various hash algorithms with various inputs and hope to get lucky. There aren't all that many commonly used hash functions. Being the hash is only 64 bits, it's probably only a portion of the full hash. When you shorten a hash, you typically just grab the first or last N bits, though some dev may have gotten creative and grabbed only the odd bits or something.

That said, I suspect that you will not find a match. Smartcards generally have a secret that is embedded in them that cannot be extracted (excluding techniques used on poorly designed/manufactured chips that involve acid baths and x-rays and such). This secret is then used in cryptographic operations (eg: HMAC or digital signature) which are performed on the card. Being that the secret is only known to the card (in the case of asymmetric crypto) or the card and card issuer (in the case of symmetric crypto), an attacker cannot reproduce the cryptographic operation. So, while you are sure you know what the input is to the card, it is likely that the input to the crypto operation is a combination of those inputs and the unobtainable secret that is built into the chip.


how does the key size and algorithm strength affect encryption strength

Bigger key size means, harder to crack. Also note that an 256-bit key is not two times harder to crack from a 128-bit key, but many many times harder.

An algorithm uses difficult math functions in order to decide how to encrypt/decrypt, making it impossible for an attacker to bruteforce and find out the key.
An algorithm might use harder math function than another algorithm thus requiring more time to encrypt/decrypt. Also the algorithms might have "bugs", making it easy to find out a few bits of the key, meaning an 256-bit algorithm to actually have 250-bit of true encryption since the 6 bits can be calculated easily.

I've heard you can figure out 1 bit in the AES algorithm easily, but still in order to crack AES and find out the rest of the bits you will still need many years, since you will have to find the rest of the key through bruteforce.

If enough bits of an encryption algorithm are easy to figure out, then the algorithm is "cracked", and its possible to find the key easily.


Break encryption by applying accidental-overwrite techniques

No one has ever actually demonstrated successful recovery of overwritten data on  a modern hard drive. It's an urban legend stemming from the days of hard drives with capacities orders of magnitude lower, which had enough inefficiency in their data storage that it was potentially an issue. See this Wikipedia article and its references.


When should server side sessions be used instead of client side sessions?

For example, is it safe to put a csrf-token in a client side cookie, whether it is encrypted or not?

Yes. OWASP calls this method Double Submit Cookies. I have never seen it in practice though.

The reason this is safe is that CSRF tokens are temporary values. For example, if you would store an encrypted password in a client side session, that would be pretty bad (depending on the key and encryption algo). An attacker may be able to steal it, decrypt it, and then have the users password. For the CSRF token, an attacker gains nothing. Additionally, it doesn't affect server security if an attacker or user changes the cookie, all that will happen is that the token doesn't work.

  in what circumstances would it not be safe to store session data in the cookie?

There are two things to worry about here:

A user or attacker may change data in the cookie and the server would have no idea that this happened, accepting the changed data (for example, it may contain a value such as isAdmin:0, which may be changed to isAdmin:1).
The cookie could contain sensitive information which a user or attacker may read out

To solve the first point, a MAC could be used, to solve the second point, the cookie data should be encrypted.

Before you create client side sessions, you should ask yourself if you really need it (which may be the case if you have multiple servers which need to share the same session state, eg for scalability reasons). Session data is traditionally handled server side for a reason: It contains data that the client should not be able to read or change. That's easiest to do by just not sending it to the client.

Setting up a complex system to store session data client side is difficult, and a lot may go wrong doing it. If it's not necessary, just store the data server side.