First:

Don't use work computers for personal use, people!

Many network policies forbid personal use. Our policy states that personal use is not forbidden but is monitored. If you don't want to be monitored you need to use equipment you control.

TL;DR: If you don't want your parents to know you smoke, don't smoke in front of your parents.

Work Equipment

If you are using a work computer, yes, if they want to, they can monitor everything you do. All they have to do is install software on your computer (which is actually their computer) which logs all web browsing activity.

If I caught someone using Tor in my organisation (absent special permission) I would fire them on the spot, for violating half a dozen policies, including circumventing our protections against data exfiltration, required both by data protection law and our agreements with our customers.

Own equipment

If the equipment is owned and controlled by you, I am wondering why they have given you permission to connect it to the network.

If you don't have permission, then again, that is grounds for termination.

If you have permission

If you are using your own equipment, and you have permission to connect to the network, (for example the company supplies visitor Wi-Fi as a courtesy, and allows staff to use this) then you are in the same position as when you use a hotel, coffee shop, or fast-food restaurant Wi-Fi, and there is then nothing special you need to know.

So what should you do?

If you want to e.g. email your doctor about your cancer diagnosis without alerting your employer, you should do it from your smartphone, using the data connection.


Is it secure to split information into multiple packets?

Intuïtively: If sending the data as a whole is secure, then splitting it must be secure too, because the attacker can split any data themselves however they want.


Do blue teams plant CTF like canaries across infrastructure?

What you have described is a medium- or high-interaction honeypot, honeyusers, and honeyrecords. The technique has been around for many years.

Honeypots within the perimeter of your network can be very useful, but should be low-interaction honeypots. Even a server with a SSH service running without any valid logins can be a useful honeypot. Any login attempts are immediately suspicious.

High-interaction honeypots are used outside of the perimeter to learn how attackers are approaching your assets and to gather info in order to raise specific defenses.

Anything you place in the hands of an attacker will be used against you. So you need to protect yourself from your own attempts to track an attacker.

If you do some reading on honeypots and other deception technologies, you will get a sense for what is seen as best practice.


Methods to Prove Data Authenticity from Potentially Compromised Sources?

Solved problem - use signatures but place no value on self-signed data.


Finding salt is relatively easy: put the known email address as the salt for the hashes into hashcat. However, it probably won't handle non ASCII salt (e.g. random binary data).

Once you've got the salt, finding predictable email addresses (e.g. firstname.lastname@gmail.com) is easy enough, but you'd have to brute force both username and domain to find the addresses from a completely unknown space - checking if a given address was present would be easy, but finding all that were present originally is hard. For comparison, even a 12 character random password is hard to break in this way, and most email addresses are longer than that (although they are usually relatively predictable).

That suggests the best way to find out the contents of the list is to find the salt, then hash a list of email addresses to see if there are on the list. Since email addresses are generally not kept private (else it's quite hard to email someone), they are regularly scraped from any databases that get exposed accidentally, and put in big lists on places like paste bin. Unless your email address is only used with trusted contacts, chances are it appears on at least one of these lists already...


Does the legality of pentesting without permission depend on its success?

So the precise answer will depend on the jurisdiction in whereever you are and the the precise Computer crime laws in place in that jurisdiction, however a general point can be made about the example provided.

By placing a website on the Internet and not protecting it from access, it is arguable that this is a statement of intent for the content of the site to be publicly available.  If you think about it how do you know that the owners of any site you visit intended the information to be publicly accessible, you don't, so the presumption is that basic page access is allowed.

The example you have as the second part is clearly a directory traversal attack intended to access a file which would not generally be intended to be made public.  The defence of "I thought ../../etc/hosts was a picture of my cat" is very unlikely to be acceptable to a court.

A more grey area example would be something like a case where it's allowed to access http://somesite.com/document?itemid=4000 but not http://somesite.com/document?itemid=4001


Each line consists of a timestamp (T=) and four variables (L=, M=, N=, and X=) in HTML-encoded format (var=val separated by &).  Of these, only the variable X requires decoding, and it is base64 encoded.  However, the decoded value is binary data, and not much useful to humans:

$ echo -n fH6MMvw38rPIs/BF2YCulBUMBS94+qEM5lZWUQ0izn1WY+RWnBBiiuuqOHQ3omFirWOrq7Kc1ug9U/4p7tw4JsCQo+V2PChm+CdEpjMNQqehUW/yoiwBpKUfWVH3N2WATTaOsbDJcRk1sQ7qG21hXgnnAODuWe7QTwrgfg== | base64 -d | hexdump -C
00000000  7c 7e 8c 32 fc 37 f2 b3  c8 b3 f0 45 d9 80 ae 94  ||~.2.7.....E....|
00000010  15 0c 05 2f 78 fa a1 0c  e6 56 56 51 0d 22 ce 7d  |.../x....VVQ.".}|
00000020  56 63 e4 56 9c 10 62 8a  eb aa 38 74 37 a2 61 62  |Vc.V..b...8t7.ab|
00000030  ad 63 ab ab b2 9c d6 e8  3d 53 fe 29 ee dc 38 26  |.c......=S.)..8&|
00000040  c0 90 a3 e5 76 3c 28 66  f8 27 44 a6 33 0d 42 a7  |....v<(f.'D.3.B.|
00000050  a1 51 6f f2 a2 2c 01 a4  a5 1f 59 51 f7 37 65 80  |.Qo..,....YQ.7e.|
00000060  4d 36 8e b1 b0 c9 71 19  35 b1 0e ea 1b 6d 61 5e  |M6....q.5....ma^|
00000070  09 e7 00 e0 ee 59 ee d0  4f 0a e0 7e              |.....Y..O..~|
0000007c


How can I secure the state of a compromised iPhone for evidence of evil before resetting it?

First: This phone hacking sounds like a bluff. It's absolutely not trivial to break into an Iphone. There are some preconditions to accomplish this like a jailbroken phone and a side-loaded app or at least a malicious app which is registered as device administrator. This will require some social engineering. For sure it could be possible that he had physical access to the phone to infect it manually... But if this is the case she got a much bigger problem than a compromised device.

But lets assume that he would have managed to break into her phone. Number one rule in such cases is: Call the forensic guys as soon as possible. Everything you do could destroy evidence or raise the attention of the attacker. After that, you can try to lock him out of the accounts and make things secure.

Anyway. If you are sure enough that an attack on the phone or some accounts happened: get the police involved and make sure nobody else is touching the phone until things are clear.


What is the entropy of just 1 Diceware passphrase like my passphrase?

You're worried that you might by accident take a passphrase that comes early in the list, which would cause your passphrase to be guessed a lot earlier than one might expect on average. Here are two reasons why this worry is baseless.

Your passphrase is (if you're doing things correctly) already randomly generated. This means that there is (e.g.) a 1/100 chance that the first word of the passphrase falls within the first 1% of the list. This is independent from the order of the list, and is independent from the order in which the attacker tries passphrases. Shuffling the list would not change that: the first word of your passphrase would still have a 1/100 chance of being within the first 1% of the shuffled list.

You cannot know the order in which the passphrases will be cracked anyway. Any reasonable passphrase cracker is massively parallel. Furthermore acceleration techniques (such as rainbow tables) lead to making attempts in an order that is pretty much random (on a cognitive sense, if not in a cryptographic sense). You do not know the attacker's crack sequence.


Identifying stream cipher algorithm based on encrypted content

As usual: if the encryption is any good, then its output is indistinguishable from randomness (indeed, a cryptographically secure PRNG is really the same thing as a stream cipher using the "initial seed" as key, and encrypting a long sequence of zeros). In particular, a specific algorithm cannot be identified.

For identification, look for context. The used algorithm, in any system, is not usually a secret; Auguste Kerckhoffs has famously explained that indeed a "secret algorithm" is not a sane foundation for secrecy, and the algorithm can and even should be made public. Therefore, many communication protocols include fields which make explicit the used algorithm; this makes such protocol potentially upgradable to new algorithms in a backward-compatible way (this is called algorithm agility). For instance, in SSL/TLS, the set of algorithms is stated plainly, unencrypted, in the ServerHello message, so everybody (including any eavesdropper) perfectly knows what encryption algorithm is used.

Similarly, if encryption is applied, then it is done in two places (the sender and the receiver), both involving a tangible incarnation of the algorithm. In shorter words, there is some software that does the encryption and the decryption. Software is highly susceptible to reverse engineering and the algorithm can thus be identified.

The RC4 stream cipher is widely used as a stream cipher (it is the stream cipher supported by SSL, for instance), and it has biases. Cryptographically speaking, it is "broken", albeit not sufficiently to turn the bias into actual attacks in most practical situations. You may be able to exploit such biases into an algorithm identification, especially if you can make it so that the unknown encryption system processes a lot of bytes that you know (you need to be able to make the system encrypt or decrypt bytes that you know, and observe the result). See the Wikipedia page for pointers.


Should I email contents of a https form submission

I'd advice against sending all that information in an email.  Mail-storage is probably not the problem, but SMTP is terribly insecure (not encrypted, usually easily MITMed even if there is TLS support available).

If you are set on sending a confirmation mail, leave out sensitive information like the person's date of birth.  IANAL (nor do I live in Britain), but I'd argue that, while all of this is personal data, the date of birth is the most sensitive as it can be used to cause actual harm.  It is frequently used as in security questions.

Re-display all details on the confirmation page visible after the form has been submitted and allow the user to download it in PDF format.

Ignore regulations for a moment and look at it from a user point-of-view: entering private data requires a certain amount of trust into the entity receiving the data.  Users are more likely to trust you if they have reason to believe that their data is kept save. Offering a form over https is a decent indicator that data won't carelessly be flung around the internet.  Sending the same data back to the user through an potentially unencrypted connection (i.e. email), allowing for passive eavesdropping, immediately breaks that trust.  I've seen instances of this happening and users were not happy about it.


Does it make sense to encrypt database to comply with GDPR?

On Compliance

I'm only loosely familiar with the specifics of the legislation, but as I understand it, there's nothing to indicate that database encryption is required to hold personal information and be in compliance with the General Data Protection Regulation (GDPR).

On the other hand, using appropriate encryption measures will somewhat lessen the privacy impact and notification requirements should there be a breach.

  (3) The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

  a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

  Excerpt from: https://gdpr-info.eu/art-34-gdpr/

On The Benefits of Encryption for Database Security

Encryption can significantly reduce the impact of a data breach. For example, in 2015 Patreon was breached, losing control of 15GB of data. To their credit, Patreon used strong bcrypt hashes to protect passwords, and had used secondary encryption measures to protect sensitive information like Social Security Numbers and tax information.

Had they not encrypted the information, the impact of the breach - both for Patreon and their users - would have been considerably worse.

On Key Management

If your concern is that an attacker would be able to access the key anyway, there are some steps you can take to mitigate that risk.

Ultimately, unless you use a Hardware Security Module (HSM), protecting keys is basically like playing a shell game with the attacker. One reasonably effective way to keep keys protected is not to store them on the server at all. One of my favourite solutions for this is the Azure KeyVault service.

By keeping the keys out of permanent storage on the server and retrieving them only for use from memory, it makes it considerably harder for an attacker to retrieve the key. You'll still need to store keys to access the keys... but adding that extra layer of indirection will make it harder for your attacker.


Is it safe to use Orbot with the normal Firefox browser on Android

Using normal browser such as Firefox for Android, while browsing, does not provide required privacy standards, that Orfox/Orweb provides.
To be more specific:

Orfox adds patches at the Android Java code layer to enable proxying of all Java network HTTP communications through the local Orbot HTTP proxy.
It also removes Android permissions for Contacts, Camera, Location, Microphone and NFC.
Features like WebRTC and support for interaction with
Chromecasts or Roku devices are removed, due to lack of compatibility
with proxying communication through a TCP-based network like Tor.

  Source: Orfox: A Tor Browser for Android - Guardian Project


Can opening media (e.g. video, image, text, etc) typically leak data to disk and to memory? Are there relatively safe programs to open media?

Does opening a video file only write to memory and not to disk?

That depends on the video player. There is no fundamental reason that a video player would need to write to the disk, but I cannot guarantee that there is not one somewhere that saves things to disk on its own. If you have swapping enabled, then some memory from the video player may be written to the disk in order to free up memory. You should either use encrypted swap space, or disable swap to avoid this issue.

  If it does write to memory, how easy is it for a relatively sophisticated attacker with hardware access to recover the media from memory?

Very easy. Forensic tools like Volatility can view the process tree from a memory snapshot and dump individual processes. Analysis of those processes will allow reading buffers containing video data out from the program. Getting the memory requires only being able to plug in a PCIe device and mounting a DMA attack. Most systems do not protect from this.

  Are there secure programs to open and play such a video file without leaving a recoverable memory footprint? Follow-up: can this be practically done without Tails?

How do you expect a video to be played without anything touching memory? If your worry is about residual memory after the program closes and the system is shut off, just make sure you have modern memory (anything newer than DDR2) and powering off the system will result in data in memory vanishing in seconds. Note that video data may also reside in VRAM on your graphics card for a short time as well, and cold boots on graphics cards are possible.

You can use encrypted swap along with full disk encryption and ensure your system is powered off before "they" get to it. That way, even if video contents are written to the disk, at least it is encrypted.

  Repeat 1, 2, 3 for images and text.

This all applies equally to images and text. Video has a larger memory footprint, but just being small does not make something immune from being written to disk or remain in memory.

I agree with @SteffenUllrich. You need to define your threat model. For each of his example threat models, the following should hold true:

  Is the media still playing if the hacker gets access to the device?

In this case, the attacker would be able to read anything from memory. There is no effective way to prevent this. Solutions that encrypt entire memory are often highly experimental, limited in scope, or extremely slow. Some newer AMD processors come with the ability to encrypt all memory, however, which would be ideal for these purposes if you expect the attacker to get their hands on the system but are unable to compromise it (e.g. limited to cold boot attacks, not DMA).

  It is done playing but the device is not rebooted?

If it's done playing then some data may still reside in RAM. This data would most likely include parts of the page cache which cache recently accessed files. This can stay in memory for a long time. Additionally, when a process exits, the kernel frees the memory it used but it does not initialize the memory to zeros until it is requested by another process. The PaX hardening patches allow it to initialize the memory immediately when pages are unmapped or the process exits, and there are new kernel configuration options which can "poison" memory on free, at some performance cost.

  Was the device shutdown or rebooted?

If the device was shut down completely, everything in both system RAM and video RAM will have been destroyed in a matter of seconds. DRAM works by storing each bit of information in a very small capacitor, and refreshing any charged capacitor every 64ms so it keeps its charge. Reading a bit involves checking the state of the capacitor, and setting a bit involves either charging or discharging the capacitor. When memory loses power, it is no longer refreshed, and every capacitor rapidly decays to the same state (with microscopic sizes of these capacitors, charge is leaked very fast).

But how does this apply to a reboot? The problem is, a reboot does not cut power to DRAM, it merely resets the CPU and some devices, which means the DRAM continues to refresh, keeping its old contents until overwritten. After all, RAM doesn't know what state your computer is in. It just knows that it has been configured and is receiving power. There are a few reasons that this memory may not be persistent across a simple reboot:

Memory was intentionally overwritten before a reboot, as it is in Tails.
Your BIOS is configured to test all memory during POST after a reboot.
You are using ECC RAM, which by design must be reset to a specific state after reboot.

In the end, you should probably be using Tails as it is designed with anti-forensics in mind. There are only a few things to remember in order to prevent an attacker from recovering video history:

Do not save any data to an unencrypted storage medium. Stick with Tails' encrypted persistence.
Make sure you never leave your computer unattended, especially while it is running.
Make sure your system is powered down before allowing anyone to get near your computer.
If someone has unrestricted physical access to your computer, it's not your computer anymore.


Can CRL and CA Issuers urls contain spaces?

Generally URL cannot contain Space and Only Allowed to Use in URL 0-9,a-z _- (dash).If you need to use space in url try it with _ (underscore). CRL is not specialized URL and same rule apply for them as well.


There are a large number of organizations, search engines, and bots which are scanning the entire Internet on a regular basis to see what ports are open and what versions of services exist. An example of a site doing this type of work is scans.io Most of this activity is not harmful.

There are even tools like masscan and Zmap which allow anyone to scan the entire IPv4 space for a given port/service in just a few minutes and you can see samples of the types of data collected at sites like scans.io

Without more information about the packets themselves it would be very hard to tell you if these were malicious in nature but most likely this is just typical Internet traffic. That said it would be wise to dig a little deeper and see if this is related to process activity on your system and see if your system, or the software on it, isn't the source for this activity.


Exploiting buffer overflow leads to segfault

Your memory address 0xbffff880 is most likely non-executable, but only read/write.  There are a couple of ways you can overcome this.

If that is a stack address you can use -z execstack while compiling.  This will essentially make the entire stack memory executable.
For a more robust solution you can write the shellcode to call mprotect on the address you are writing to.

For example, the following line will mark address 0xbffff880 as read/write/executable.

mprotect((void*) 0xbffff880, buffer_len, PROT_READ | PROT_WRITE | PROT_EXEC);

-fno-stack-protector does not mean that the stack will be executable.  It only disables other security features such as canaries or stack cookies. If these values are overwritten (with a buffer overflow) when they are checked the program will fail.  This would not enable the execution of your buffer.


SSD Hardware Encryption versus Software Encryption

...  I would love to hear what others suggest.

Looks like at least Microsoft does not trust the internal encryption in SSD anymore. It switched to software based encryption for BitLocker by default:

  BitLocker, Windows' built-in encryption tool, no longer trusts your SSD's hardware protection
  After reports of widespread flaws in hardware-based SSD encryption, Microsoft has pushed out an update that defaults BitLocker protection to software-based AES encryption.


I rent a virtual server at a hosting company.

You are ultimately trusting this company, as it has unlimited access to all your data. Choose wisely, e.g. put more value to the security and privacy than to the price.

  There I have a self-signed certificate installed.

A certificate is only for authentication; it doesn't tell anything about the encryption used for the connection. Use only current TLS versions with recommended strong ciphersuites i.e. TLS 1.2 with RFC 7525, 4.2 or TLS 1.3 with its mandatory ciphersuites from RFC 8446, 9.1.

If others are using your service, consider using e.g. a free Let's Encrypt certificate instead of a self-signed one, as the authentication would then use a public-key infrastructure (PKI) and be automated; if people are supposed to check the certificate manually, they'll just accept any certificate.


HPKP is TOFU(Trust On First Use). So if a user system compromised, but the browser still retain the pin, when the malware redirect the url request to a fake certificate to their phony proxy. the browser will show error like "SSL_PINNED_KEY_NOT_IN_CERT_CHAIN" (varied depends on browser).

However, there is some site doing it wrongly, e.g. as report by Netcraft : HTTP Public Key Pinning: You’re doing it wrong!

In addition, because its TOFU nature, HPKP is not bulletproof to MiTM.

However, if you have an webapp/mobile app that inherit pin for HPKP, then your webapp are protected from MiTM attack if implemented properly


How to determine all public IP adresses from within an organization?

This is not possible.

As you mention, you will have a route (or a few) to get out of your network and you can see the outbound public IP address for there.

This may be only one of the many addresses allocated to a company. In particular, this outbound IP address may not be the one you would use to access publicly facing services (in a larger company this is very likely).

The non technical way could be via an ARIN / WHOIS search. The information you will find in there is as up to date as the network admins made it to be.

Then you can try to check the services you know about (www, ftp, ...) and may find an IP address which may or may not be one your company is an owner of (the web site may be hosted elsewhere for instance)

Except for asking the network admins there is not reliable way.


How can my employer be a man-in-the-middle when I connect to Gmail?

You are absolutely correct in your assumptions.

If you are using a computer owned and operated by your employer, they effectively have full control over your communications. Based on what you have provided, they have installed a root CA certificate that allows them to sign a certificate for Google themselves.

This isn't that uncommon in the enterprise, as it allows inspection of encrypted traffic for virus or data leaks.

To answer your three questions:

Yes it is very possible, and likely. How active they are at monitoring these things is unknown.
Your password can be read in plain text by your employer. I don't know what you mean about the web server.
You can check the certificate to see who signed it, as you have already done. You can also compare the fingerprint to that of Google (checked from a third party outside of business control)

Edit:

  How exactly is my employer able to unencrypt that? Could you perhaps
  elaborate on that a bit?

You are using the bad certificate to connect to an intermediary device such as the firewall, that device is then connecting to Google using the correct certificate. The communication is encrypted from your client to the MITM, decrypted, and then re-encrypted on its way to Google.


Trying to get rid of hackers who have access to all my devices

First, use a known clean computer (not related to anything you had and not connected to anything you have now) to clear up all your online presence, especially various cloud storage services such as icloud/googledrive/dropbox/onedrive. Close up any unneccessary accounts and get your email in order - it often is the key point that must be secure. Set up two factor authentification where possible - if you believe your phones to be affected, you can get a cheap dumbphone for the 2FA sms'es and such. Don't login to the email from any of "your" systems before your cleaning is done.

Second, disconnect your computers and check up your network infrastructure. If all your devices are affected it may be that you have something like a wifi router that's compromised.

Third, nuke and reinstall the computers. And hope for the best.


Reflected XSS - Automatic understanding of filters

You could probably use Burp Suite to do this.  Burp Proxy will let you intercept an HTTP request to a specific URL, http://www.test.com/login/?login=[PAYLOAD] for example.

Once you have intercepted this request you can specify which of the parameters you would like to target using Burp Intruder(in this case login).

Next you can specify a payload that you would like to apply to this parameter.  You can choose from a number of existing payloads or you can create your own.

When you begin the attack it will fire a request with every item in your payload set and give you a number of options for examining the result, such as grepping for the payload to see if it made it through intact.

Hope this helps!


Which SSL/TLS protocol will use by cURL if not defined?

The SSL protocol involves a handshake where the version is negotiated. The web server and the client will agree on the newest version that they both support. As cURL supports TLS 1.2, the newest standardized version, the version of TLS chosen will correspond to the highest version that the server supports unless you restrict cURL's SSL options.

Googling SSL handshake will give you many references on the version negotiation.


How to protect and detect DNS manipulations from browser side?

I'm afraid we won't have a proper solution until we get everyone to use DNSSEC.

However, I predict that unless someone discovers a really critical flaw in DNS protocol forcing everyone to implement it, it will take many many years ☹ (just look at IPv6).

As a partial solution, you could have the DNS resolver set to a trusted DNS resolver which also signs all unsigned responses with its own key. That won't detect that the dns server provided on the DHCP response is malicious/poisoned, but -adding the appropiate code on the stub resolver- if all DNS queries where answered by the evil DNS server, you could notice that.


Decrypt TLS 1.2 traffic between .NET Windows applications

Assuming the applications aren't using certificate / public key pinning (or that you can alter the pins if they are), your best bet is almost certainly an intercepting proxy.
There are a number of intercepting proxies out there, but I'm most familiar with Portswigger's "Burp Suite" and the free version of it will work fine for this, so I'll generally assume you're using that (you could probably also make Fiddler or Zap work here). I'm going to write these instructions from the assumption that you've never used an intercepting proxy before, but note that there are tons of guides online to how to use these tools.
Install the proxy on a machine in the same network as your two applications (it can be on the same machine as the client - the one that sends the requests - but you will need to change the server app's listening port or the client's request port if you want to install it on a machine that ever acts as a server) and start it up. If you're using Burp, it's a Java app and will run on anything (Win/Mac/Linux/etc.) with a suitable Java installation. The proxy will generate a "fake" CA key pair for HTTPS; you'll need to export that public key and install it as a trusted root certificate authority on the client machine(s). Set the browser proxy settings to use the IP address and port where Burp is listening (let its listening port through the firewall if needed) and test whether you can browse HTTPS sites using the browser, and whether they show up in Burp's log. If so, you're good to go.
It's possible your .NET app will respect the system proxy setting, in which case you don't need to change anything else; when it tries to talk to the server it will route through the proxy, and you can see everything it sends and receives. However, most apps aren't proxy-aware. To handle that, you can set the proxy to run in "invisible" mode, where it just acts as a web server and forwards the request appropriately (you can also explicitly configure it to forward requests, as a "reverse proxy"). If your app listens on 443 or a similarly low-numbered port, you may need to run Burp as Admin/root. Once Burp is listening on the port that the client sends requests to, go to the HOSTS file on the client (\Windows\System32\drivers\etc\hosts on Windows) and edit it (will need Admin/root privileges). Add an entry for the hostname of the server, pointing to the IP address of the Burp proxy.
The client will now connect to Burp when it's trying to connect to the real server. Burp will accept the connection, negotiate TLS using its own certificates (this is why you had to install Burp's CA cert), log every request, and forward them on to the expected destination (the server) over its own HTTPS connection (which Burp opens as a client). Burp will also log the server responses, and forward them back to the client as its own responses.
If the server is identified only by IP address, you can either change the IP address in the client and configure Burp to forward requests to the real IP address (reverse proxy mode), or you can install Burp on the server and either make the server listen on a different port (which you'll set Burp to forward to), or change the client to send requests to Burp's port (which Burp will forward to the usual server port). In the very unlikely case that the server listen and client request ports are hard-coded and the server address is hard-coded and the server is identified by IP address rather than hostname... you'll need to use something like ARP spoofing to get the request routed to you, and set things up so your proxy intercepts traffic for which its IP wasn't the actual destination. This is totally possible - SSLStrip does it, for example, though not using Burp - but you'll need to look into how to set it up.

Now, with all that said, there are a few other options.

Install on the client a modified version of the System.Net.Security assembly, such that all traffic through a TLS stream is logged to a file or similar. This might be complicated by assembly signing requirements, which would mean you'd need to modify the executable as well. This is all possible but could be a hassle. Also, if you don't have such a library to hand - one might exist out there but I don't know of it offhand - you'd need to decompile the official library and modify it, or install a shim library.
Decompile the client and/or server assembly and just read what requests it makes/receives and/or responses it expects/returns. Unless obfuscated, decompiling .NET is quite easy - recent versions of Visual Studio include built-in support, or you can use a third-party program like JustDecompile or similar - and even obfuscated code can usually be figured out with some work (the public symbols can't be renamed or hidden, which helps).
Decompile the client or server assembly and modify the function(s) that handle HTTPS requests/responses to additionally log the request/response text to a file or similar. Then recompile the assembly and run it instead of the original version (just move/rename the original, don't delete it).

(Obviously, if you would get in legal trouble for decompiling, don't do it)


Yes,  this is a very serious concern when it comes to reading your email via a web browser.  In fact gmail has had this happen a few different ways.  In a broader sense,  XSS within an email could be used to spread an email based worm.  The XSS payload has access to your list of contacts and the also the ability to send email as you.  This is similar to the Sammy XSS Worm.

When it comes to a client like,  Outlook or Thunderbird this really isn't much of a concern because the context in which the script executes is mostly useless to the attacker.  Although this type of vulnerability has happened and this type of XSS could be useful for delivering a client-side exploit such as a html or javascript based buffer overflow.  The pairing of XSS in thunderbird with a buffer overflow would lead to a very nasty email worm.


Why can a Tor exit node decrypt data, but not the entry node?

Tor uses a routing method called Onion routing. Much like an onion, each message (the core of the onion) is covered with layers of encryption.
image attribution

Your message is encrypted several times before it leaves your device. Node A can only decrypt (peel) the layer A, under which it would see the address of the next node. After the packet reaches the next node, it can only decrypt (peel) layer B, and so on. For each layer, you use the respective node's public key, so only that exact node can decrypt the layer with its own private key.

When the message reaches the exit node, all of the layers have been decrypted and message is now in plaintext (it could also be encrypted if you're communicating with the server under SSL).


Is there some way to protect apk file from being decompiled?

It's impossible to completly obfuscate your code. What you can do however is to compile some of your business logic into native libraries.

System.loadLibrary("yourlibrary.so");

and then invoking the natives with JNI. It would still be flawful but at least  better than using the pure code. I'm not a proficient Java developer, but a similiar feature in C# would be DllImport. It won't prevent you from being debugged but it's harder to debug, especially against script kiddies.

Oh and remember it'll be a pain to maintain, especially when you'll not be writing java to the .so file. And also remember to target multiple architectures.

From my understanding you can make it harder but not impossible. ProGuard should do fine.


The answer to your question would depend on the context in which you're interested.

If you're interested in detecting SPDY servers while browsing the web you'll first need a browser that supports SPDY (e.g. Firefox 11+ or Chrome). In this scenario the best way to detect SPDY is browser dependant.

For Chrome there are a couple of ways:

You can browse to chrome://net-internals/#spdy for a list of all currently open SPDY connections (because SPDY connections are persistent - every tab that contains a document from a server which supports SPDY should be present).
If you're interested only in the current tab you might examine the window.chrome.loadTimes().wasFetchedViaSpdy DOM property.

For Firefox, the only way I'm aware of is to look for the presence of X-Firefox-Spdy response header. Do note that for this to work, you must enable SPDY support (it is on by default as of Firefox 13, otherwise - set network.http.spdy.enabled to true.

All this depends on using a SPDY enabled browser, and manually checking servers. If you'll want to automate this, use a browser that doesn't support SPDY, or just plainly skip the browser - you'll need another strategy. As I see you have two options in this case:

SPDY servers can be configured to advertise their support of SPDY when sending HTTP responses. This would require you to inspect the presence of the appropriate Alternative-Protocol headers (outlined in the SPDY draft).
Simply establish a TCP connection to the server an send it a SETTIGNS (HELLO) or a SYN_STREAM frame and see if it responds according to the SPDY protocol.


Explain the three versions of Diffie-Hellman used in SSL/TLS

These three variants of Diffie-Hellman all operate in roughly the same way.  In all three, the client and the server pick a random number (private key), compute a value (their public key) based on that random number, and then share that public key with the other side.
In anonymous Diffie-Hellman, neither side signs or otherwise authenticates their public key.  As a result, you can determine that you computed a shared secret with somebody, but not who that party is.  This leaves you vulnerable to a man-in-the-middle attack.  Usually this is also an ephemeral key exchange.
In fixed Diffie-Hellman, one side (usually the server) presents their public key in a certificate (usually signed by a certificate authority).  If this is a signed certificate, then the fact that owner of the certificate can negotiate a successful connection is proof that it controls the key and therefore authenticity is established.  However, because this key is fixed in a certificate, if the corresponding private key is leaked, all data generated using that key is compromised.
In ephemeral Diffie-Hellman, both sides generate a new, random public and private key each time.  The server (and the client, if they are authenticated) signs their Diffie-Hellman public key with the private key in the server certificate (which is usually RSA or ECDSA).  The fact that both sides can negotiate a connection successfully and the Diffie-Hellman public key is signed proves authenticity of the connection.  An attacker impersonating the server would be limited to reusing a previous signed DH public key sent by the server, but because it did not know the private key, it couldn't successfully negotiate a connection.  Because the Diffie-Hellman key material is fresh each time, as long as both sides discard their Diffie-Hellman private key when the connection is done, this provides perfect forward secrecy.
Anonymous Diffie-Hellman is not practically used these days since it provides no authentication.  For situations where authentication is not important, using a self-signed certificate is almost as easy.  Fixed Diffie-Hellman is not practically used in TLS because ephemeral Diffie-Hellman provides perfect forward secrecy and using that with an RSA or ECDSA certificate is easier and better supported.  However, fixed Diffie-Hellman remains useful in situations where the protocol is not online and thus ephemeral options are more difficult.
Much of this also applies to other protocols, such as SSH.  However, in the SSH protocol, the signature is not over the public key, but over a hash of the negotiated secret.  This is also a secure approach and also provides perfect forward secrecy.


Windows Firewall accepts a three-second unicast response from any source

This is not normal for firewalls, although it is almost like a stateful firewall policy, at least in spirit.

Multicast applications in 2004 (the time when SP2 was released) had many latency issues and various networking 'helps' were put in place to make the experience smoother. I suspect that MS added this 'feature' to assist online multimedia.


Of course Google will warn about encrypted content, especially if it is not encrypted by themselves, hence they cannot decrypt the file. The warning comes only because they are not able to see the file's contents, not because there is something wrong with it. At all times they will prefer having control of all the variables: holding your password, the encryption keys and so on.
Now, this doesn't add up:

However, I am able to open the file without getting prompted for a password.

What is expected for decryption is a key (not a password), but still, you need something. If you can see the contents without the key, it is not encrypted, maybe coded but not encrypted.
As always, you should use good sense to decide about this attachment:

where it came from?
do you know who the source of the file is?
did you asked for it?


I have encrypted my laptop/phone. How will someone I send an email to read the contents?

When you encrypt your laptop and phone, that usually means that the data storage (hard drive, etc.) is encrypted. You decrypt the storage in order to work with the data (access programs, work with data, etc.).

Therefore, when you send an email, the email is not encrypted at all. So your recipient is not seeing anything encrypted because you, yourself, are not working with the email encrypted. When you close or shutdown the device, then the data (the sent email) is encrypted on that device along with everything else.

Encrypting a device is intended to protect against someone stealing your device and simply accessing the storage directly and reading everything. In order to read the data on your device, they need the password that decrypts it.


To meet this requirement, I think you'll want to look into a dedicated log server.

No remote access, not even SSH.
Syslog is the only service.
Credentials are unique to the logging server.

That's pretty reliable.  Depending on your case, it could be anything from a pimped-out, highly reliable commercial chassis to a RaspberryPi hanging on a nail.


In Kerberos, how does a client authenticate the KDC?

I think there are two different but related answers to your question.  Initially, the client needs to know what KDCs exist to handle authentication requests.  In a Windows Active Directory environment this is handled through Kerberos service records in DNS.  The client trusts DNS to provide a valid list of KDCs.  But this does open up the possibility of an attacker compromising DNS in that environment and adding a Kerberos record for their fake KDC.

However, the 'real' authentication is based on the how the KDC proves to the client that it is a valid KDC during the initial authentication process.  In its response to the client's request the KDC sends the client a session key encrypted with the client's secret key, or long term key.  That secret key is based off a hash of the client's password.  So if the client can't decrypt the session key it knows that there is a problem and the KDC it's talking to may be fake (or just not synced up with the latest secret key).  The authentication process then fails.

At that point the client hasn't even sent its password hash to the fake KDC, so even a compromise of DNS doesn't really expose the client to unreasonable risks in this regard.


Is using a server as bridge secure enough to protect the end data?

As long as the AWS London server, not sure how the server location is enforced, supports a secure (HTTPS) connection, any kind of bridge that doesn't break the connection should be fine.
You can accomplish the same thing simply by using a commercial VPN and selecting a Europe based access point.
Legally mandated location access restrictions are doomed to failure.


There are two situations in which you would want to control the Referer header. By the way, Referer is a miss-spelling of the word "referrer".

If you want to control your personal browser not to pass the Referer to site2.com, you can do that with many browser extensions:

For Firefox there is RefControl (which I use and am happy with. I use the option "Forge- send the root of the site")
Chrome has Referer Control

The other situation is where you are a webmaster and you want the users of your site (site1.com) not to send the Referer to other sites linked on your site. You can do that in multiple ways:

Use SSL/TLS (https) on your site and a security feature of the browser is not to pass the Refererto HTTP links on your pages served up with SSL/TLS. However, if the links on your pages use HTTPS, then Referer will still be passed over unless explicitly turned off by other means described below.
Use the HTML5 rel="noreferrer" attribute. It is supported by all major browsers.
Use a Data URL ('data:') to hide the actual page the link is coming from: <a href='data:text/html;charset=utf-8, <meta http-equiv="refresh" content="0;URL=&#39;http://site2.com/&#39;">'>Link text.
Hide the Referer by redirecting through an intermediate page. This type of redirection is often used to prevent potentially-malicious links from gaining information using the Referer, for example a session ID in the query string. Many large community websites use link redirection on external links to lessen the chance of an exploit that could be used to steal account information, as well as make it clear when a user is leaving a service, to lessen the chance of effective phishing.

Here is a simplistic redirection example in PHP:

<?php
$url = htmlspecialchars($_GET['url']);
header( 'Refresh: 0; url=http://'.$url );
?>

  <title>Redirecting...</title>
  <meta http-equiv="refresh" content="0;url=http://<?php echo $url; ?>">

 Attempting to redirect to <a href="http://<?php echo $url; ?>">http://<?php echo $url; ?>.


How can an "alternate" or duplicate HTTPS certificate be used in an attack?

For SSL itself, a fake certificate can only serve as a way to run a fake server. This requires intercepting the connections from some clients to the true server, and redirect them against your server. Manipulating the DNS is only one way to do that (admittedly, often the easiest) and DNSSEC is meant to protect against that (since DNSSEC is about "securing" with signatures what the DNS servers return). If the attacker controls a router/firewall between the client and the server, he can redirect all the traffic he wants without needing to change anything in the DNS.

Your point #2 is more a Denial-of-Service than anything else. It highlights that when heavier authentication procedures are put in place (e.g. the procedures which are conducted before issuing an EV certificates), it makes mishaps less probable (harder for the attacker) but also deeper (recovery might be longer). This is a point which must be taken into account in the whole security trade-off.


Is CIFS/SMB (Folder Sharing in Windows) secure?

no, you could be MITM'd unless you're using AD and/or IPsec
passwords are encrypted
the data is in the clear
yep, it's a nightmare to keep on top of Windows SMB/CIFS holes.  You also have to watch for being brute-forced.  Even if you limit it to one account, that account has access to all the data, and privilege escalation on SMB is not unheard of.

The VPN would be simplest if you're locked to SMB.  You don't want to expose your clients to the Internet anyway, so VPN to the firewall for all of this kind of traffic.


Is Salt, IV and Key necessary when encrypting password in a database using AES? If so, how should they be used?

When encrypting the user password to store it in my database using AES-CBC, do I need to use a Key, an IV and a Salt? Whatever I need to use, how would they be used exactly?

The IV is used to initialize the first 16 byte matrix of the AES-CBC encryption scheme. It is XORed with the first 16 byte of the message. This means that, if the IV is constant, the same message will always output the same ciphertext. On the other hand, if the IV is different on each encryption run of the same message, because of the XORing of the IV with the first block, the ciphertext will always be different, since the result of the XOR will be different. IV is an inherent part of AES-CBC, and you will always have to use an IV, the choice is whether this IV is constant or not.

The Salt is a random message that you prepend to the real message so that on every encoding of the real message, you are actually encoding a different looking message (salt + real message) which will result in a different ciphertext. This is normally used for hashing algorithms, in order to get a different hash on each run of hashing of the same message.

You do not need to use a salt with AES-CBC, because the IV is already having the effect that the salt is designed to have. But if you want to use a salt, you can, and here is what would happen. Say you had a 16 byte salt, it would be prepended to your message, so you would have (salt + message) as the input to be encrypted by AES-CBC. Being 16 byte, your salt would fit in the first block of AES-CBC, it would XORed with the IV and as a result you would have (salt XOR iv). This result of (salt XOR iv) would then be used as the IV for the second block, which in this case, would be the 16 first byte of the real message.

Therefore, in the case of AES-CBC, using a salt only has the effect of an extra processing on top of your IV. If your IV is constant, the salt will XOR with it, resulting in a new IV to the second block that is different for each run of the encryption, even though the IV is constant.

So in conclusion, you are better of just using a random IV and not using a salt at all. Or use a constant IV and have a random salt (but watch out for this, go see #2 below for details). Both of these will have the same effect, which is to generate a different ciphertext on each encryption run of the same message.

  1) The random IV I am passing to AES will have the effect that no two "mypass" gives the same ciphertext. Doesn't this make the salting redundant, because the point of the salt is to prevent two ciphertext of the "mypass" to be identical?

Yes it does. The IV and the salt effectively have the same effect, and help protect against the same attacks. Do note that, for the salt to have the same effect, proper thought in it's implementation must be considered, see #2 below for more details.

  2) Inversely, could it be that the IV is redundant, and I could just pass in the zero IV or a constant IV since I am salting my passwords?

Not so fast. A lot of things must be put together properly for this to be true. Depending on the mode of AES, it might not always be true that the salting will result in the desired behaviour. Your salt length and the way you concatenate it with your message must also be right, appending could lead to problems for long passwords for example. Therefore, it is better to use the AES as it was thought of, that is, use a random IV and no salt.

  3) Say the IV and the salt are not redundant, because somehow I read without really understanding that the IV is XORed but not the salt, making both useful. Is it enough for me to properly salt to simply prepend "mypass" with the salt?

The IV is XORed with the first block of AES in mode CBC to be encrypted. If you use a salt, the salt will be XORed with the IV in the first block, and this (IV xor Salt) will effectively become the IV of the second, which given a 16 byte salt, would be your actual message to be encrypted.

  4) Am I somehow supposed to use the salt to derive the key that I will use for encrypting "mypass" with AES? Or am I doing it right by simply using a hardcoded key?

You shouldn't ever derive the key from the salt. The salt is not secret, and therefore, if you were to do that, the key would be easily found from the non secret salt. I was getting this confused with password based encryption, where you use a key derivation function to derive the key from a secret password.

  5) What am I supposed to store in my database? Should the salt, the iv and the ciphertext all be stored in individual columns, or should they be somehow combined together, if so, is simple concatenation enough, or they must be combined with a special function?

From what I understood, this doesn't matter, as long as you know how to retrieve them. You can either use different column, or combine them together in one somehow.

  6) Am I completely wrong and if so, what should I do instead?

Basically, I am using AES-CBC as a hashing function. Where normally the 256 bit key of AES means it is very hard to brute force, this bypasses that because here you can brute force the combination of the message, since the message is a password, chances are it's a lot shorter than 256 bits to brute force.

The other issue is that, being a symmetric algorithms, if a hacker compromises the server, and gets the key, he does not even need to brute force, dictionary attack, rainbow table, or anything else, he can just decrypt all passwords.


What you have thought through on your own is the standard way of doing encryption for network traffic:

Generate a random symmetric key,
Encrypt entire "message" using symmetric key (plus IV, nonce, etc),
Encrypt symmetric key using target's (in this case, your central server) public key,
Destroy the 'plaintext' symmetric key,
Ship the encrypted goods to the destination(s).

Your concern regarding PRNG is correct.  Since you are probably using an encryption package of some kind (usually a library in your programming language), there is probably a cryptographically-secure random number generator in that package.  Do NOT rely on standard PRNGs (rand(), rnd(), etc).  Also, make sure that the encrypted bytes are converted to a usable format for transmission, as most common transmission protocols tend to choke on raw binary.  Base64 "ASCII armor" is the standard.


Safe way of accepting customer-supplied private keys?

One of the cardinal rules of X.509 is that private keys do not need to transit between entities ever.  They can, certainly, and encrypting them is the correct way to do this safely (password-protected PFX files are encrypted using the passphrase to generate a symmetric key; OpenSSL exchanges encrypted keys in a similar manner but lets you explicitly choose the cipher).  Exchanging the passphrase is tricky and needs to be done offline, if you don't trust the medium of transmission with the cleartext private key.  Sending a cleartext private key and sending it encrypted alongside its key are exactly equivalent.

I think there is certainly a better way to do what you need to do, but it's going to be a bit of a shot in the dark because I don't understand what your service is doing with the certificates.

Generally, there are a couple goals in a setup like this:

Mutual authentication between two endpoints
The ability for one party to certify new users

It looks as though you want mutual authentication to be done using certificates in both directions (client certificates).  You can do this without sharing a private key!  The certificate your servers present only needs to be trusted by the other endpoint, not shared.  So, you can exchange the fingerprint, or you can have them certify a certificate request you (automatically) generate.  Or, you can generate a self-signed  certificate they can trust.  That's all you have to do - the certificate request, fingerprint, and certificate without key can be exchanged safely with very little risk.

As for the other side, the client can send you a CA certificate that will issue credentials.  You don't need the private key to accept them, because you can validate the client's certificate against the CA certificate with which it is signed.  Generally this CA certificate should not be trusted for any other purpose.  This done, the client can sign all the certificates they want into authenticity, and you can either use the subject name to infer the existence of a user, or create an association between the certificate and a user in your own way.

They can safely send you the client certificates without the private key.  In fact, they do this every single time they use one to authenticate.

If you do this, you create a disjoint PKI.  The server authentication certificates and client authentication certificates aren't signed by the same CA; this works fine.

The clients and your servers must install the client CA and your server certificate or CA.  The latter could easily be signed by a well-known CA, saving one step; installing the client CA (the CA which issues the client certificates) is standard procedure when using client certificate authentication and is probably already done in your implementation today.  If you like, you can drop this down to one CA, by having a third certificate sign both those CAs (you don't need to exchange private keys to do this either; just the CSRs, containing only the public key).  Then, everyone can trust that CA (again, they only need the public key to do this).

As a general simplified rule, the only time you need the private key for a certificate is if you are signing something with it ("I sent this request", "this is the key you can use to talk to me", and "I attest to the authenticity of this certificate").  Validation can always be done without the private key.

There is something funny about the way you are using X.509 here.

If a protocol depends on the client presenting your public key to authenticate, it's little better than a static (and cleartext) passphrase.  In fact, it's worse, because your public key is something that is routinely disclosed.  For instance, when your browser visits an HTTPS website, the server sends its public key (in the form of a certificate) to your browser.  The whole point of public-key authentication is that you cryptographically sign the communications (you sign the MAC, message authentication code, which is generally a hash of the message) in a way that only you could.  The client then validates that the message was signed with the private key corresponding to your certificate by checking it against the public key (in RSA they have the same modulus, but different exponents) and that the certificate is valid.  Presenting the public certificate is only a small part of this.

But, then, that you are using the windows crypto API implies that perhaps you are in fact using SSL correctly, and just have the private key installed in places you wouldn't need it if you used two certificates.

All that said, you can safely exchange private keys as long as you trust the medium, which in this case I don't believe you do.  You could transfer them using TLS, though that of course has its drawbacks (the key is probably of sufficient value that an attacker might actually put in the effort to recover it, breaking the conditional security assumption that the cost of recovering your information is more than its value to the attacker).  If you can't trust a TLS encrypted channel for transferring it, you also can't trust the same encryption to keep it safe over the same medium in PFX (eg. AES-256 at best).  Really, the safest option is to toss it on an encrypted flash drive or something and courier it.  Exchanging public keys is a lot cheaper and faster and safer.

Sorry for the long rambling.  TL;DR: redesign your implementation to use two CAs, one for your stuff, and one for their stuff.


Are WPA2 connections with a shared key secure?

Anyone who witnesses the association process of a new client can eavesdrop on their connection.

As reassociations can be forced by a rogue host that sends a forged disassociation packet in the name of the target, it is practically always possible to listen in on all connections on a WPA(2) network with a preshared key.

You can even try it for yourself in Wireshark: There is a built-in option to decrypt all transmissions in the 802.11 settings; as long as you know the PSK and the initial authentication is contained in the recorded traffic, Wireshark decrypts it automatically for you.

The difference between WEP and WPA is that there is a different pairwise key (called the pairwise transient key) for every client, but as this key is always directly derived from the PSK, it doesn't really add any security at all. If you want that kind of security, you would have to use EAP and a RADIUS server (sometimes called "WPA enterprise), where the PMK is different for every client.


What are the cons of stateless password generators?

I have used a stateless password generator for years, and I think there are a lot of drawbacks:

If your master password is compromised, all of your passwords are. In comparison, standard password managers requires that the attacker both compromise the master key and gain access to the password store.
If a website has a password policy, you might not be able to generate a password that respects it.
If one of the password needs to be updated for some reason, you need to keep that state somewhere. For example, you need to remember to generate a password for "StackExchange2" instead of "StackExchange".
If you already have some passwords that you can't change (for various reasons), a static password generator won't help you.

For all those reasons, I think you should definitively use standard password managers.


JWT tokens are primarily designed as an assertion mechanism i.e. provide the relevant user information to allow server to "know" the user on whose behalf operation is being performed. JWT is perfect for following scenario

You can not access user information on server side without user's involvement but you need some basic information for offline calls.
JIT provisioning i.e. to transfer user details from one site to another (aka federation).
Session/Stateless operation with limited data i.e. you need specific user data with each transaction but do not have concept of session (e.g. API, event processing system)

Even though it seems to be used for session, I think, it is not the best used for the same.

OAuth is more appropriate, I think, for session management. It is designed with basic concepts like refresh token (session extension in case of session expiry), access token (session id) which easily maps to session management concepts. In case of OAuth, authentication method (like JWT) is for server to decide. After that only thing client needs for the duration of session is an access token (similar to session id). The biggest issue I have seen being raised is that access token and refresh tokens need to be stored and managed on server. If you are easily able to map the access token to session id, I think you can remove that need. But given that you are already working on storing JWT, this should be a non-issue for you.


First off: Those commands are not sloppily thrown together. They are stiched together such that they do the job.

And yes, of course they do their job. Hashing 16 bytes of entropy, expanding it to a longer (but printable) string, should be fine from a security perspective.

The definition of secure might be different for you, though. Usually, secure passwords are

long enough to not allow

brute force and
rainbow table attacks,

complex enough to not be guessed easily,
contain as much entropy as possible and
are intracktable with a dictionary attack.

All this is the case with the one liners. Please also note there is the famous XKCD about this which might interest you as well as it sheds some more light on the

  It can be actually remembered by humans

part of password security.


Is it safe to install Xampp to learn Security and Penetration testing using DVWA?

You can make it safe(r) by:
Configure Apache and MySQL to listen only on 127.0.0.1.

Apache
Edit the file C:\xampp\apache\conf\httpd.conf and change Listen 80 to Listen 127.0.0.1:80

MySQL
Edit the file C:\xampp\mysql\bin\my.ini and make sure that the bind-address is set to 127.0.0.1

Configure the firewall to block TCP port 80
Use the Windows firewall to block incoming requests to TCP port 80.


The Calculator app has a currency conversion feature, which actually grabs conversion rates from the internet. As such this network traffic is normal.

Edit: To expand on this, Windows 10 has telemetry all over the place, but how much information is gathered depends on your privacy settings. If you're willing to read through an extremely detailed page about what is collected when the "Basic" privacy level setting is selected, this page by Microsoft should satisfy your needs. There is also this page by Microsoft that goes into the diagnostic data that is collected in version 1703 of Windows 10, which also includes information on how keyboard usage is collected.


ImageMagick < 6.9.3-9 - Multiple Vulnerabilities question

I don't think you can get a solid answer for this. But not many are at risk even if they are running at risk versions of ImageMagick.

First one would have to be able to figure out how many PHP applications are live with ImageMagick installed and configured. No major CMS or PHP application requires the ImageMagick library. For image manipulation the GD2 library is the standard go to and the GD lib has been included since PHP 4.2. So if someone is using ImageMagick they would have to install and configure it to work with PHP themself. With applications like Wordpress they would then have to install and enable a plugin to use ImageMagick as well. Typically shared hosts do not install Image Magick with PHP installs either due to it's history of exploits.

Further more the install and usage of ImageMagick is not enough to make it exploitable. For example, most of the image manipulation is done on the back end of a CMS. (Uploading an image and getting different sizes the CMS can use for example.) And if the public front end is doing real time processing they would have to be able to exploit the front end code to attack ImageMagick. So at this point you are looking for 2 exploits. One to exploit the web application that interacts with ImageMagicks PHP APIs and then an exploit in ImageMagick that is possible through ImageMagicks PHP APIs.

The exploit you mentioned in your question is possible through a PHP application if all the moons are aligned. Especially if the filename input is controlled by the front facing user. But basic input sanitation or the PHP application having control over the filename should be enough to stop this attack. The proof of concept (shell.php) does not implement these but the idea of the proof of concept is to see if it is exploitable, not defendable.

So to sum this up: Not many PHP applications or content management systems are likely to be affected.


In that specific case, as far as I understand, the initial compromise was traced back to a compromised system at cPanel. The breach allowed the indirect attack of some systems which use cPanel, and the attacker was on the habit of installing a rootkit which put a backdoor in SSH.

The general methodology for understanding what happened and whodunnit is the same as in any case of post mortem debug: gather data & think hard. If many machines were compromised, try to work out what they have in common. Inspect all log files. Take a byte-to-byte image of the hard disk of an affected machine and see if there are interesting things in deleted files (most attackers will cover their tracks by deleting temporary files they used, but few will bother to actually fill the corresponding disk areas with zeros). This is called forensics and it is an expertise in its own right.


Should I be worried if I accidentally entered my password in a username field?

The short answer is that it is very, very likely that your concatenated username and password exist on an unencrypted log somewhere that a larger group of people would conceivably have access to than the restricted logs.

You are not paranoid to change your password and should change it when this happens.


Does malware beacon in regular intervals or irregular intervals?

From reading/Googling various docs and looking at incident investigations, it seems to be both. However I am looking for some advice/pointers on the following dilemma.

As you said, it's probably both. It may even depend on the mode the malware enters; it may enter sleep mode waiting for some event or date.

And there's many kinds of malware, from many different people, with many different goals. A cryptolocker for instance only needs to call home once; to communicate a key an ID number. A botnet participant will call home regularly to receive new commands; it may even open a persistent TCP connection. E.g. IRC has been used as a control channel previously.

A catch all-answer is clearly impossible.

In addition, there's lots of legitimate traffic occurring automatically, on fixed or variable times. Software updates, NTP, e-mail, etc.

  What is the downside in terms of malware coverage if I just build for regular intervals at this moment (First release) and then focus on irregular intervals later ?

This probably depends on what other characteristics you're looking for to decide if it's legitimate traffic. It's a complex question, and I believe it's impossible to judge, with the amount of information given.


Can Netflix tell whether I am behind a VPN?

They can't per se. But they can collect a list of the most popular known public VPN services and check if your IP matches with one of those VPN services. Whether they actually do that, I don't know.


A merchant can authorize and validate monetary transactions with only the credit card number.  The only reason they collect the CVV, name, address, etc. is to protect themselves from fraud.

That being said, any transaction that a merchant submits can be disputed (by you) within 60 days.  The bank must respond within 30 days.  Meanwhile you are not liable for the amount.  The bank can perform what is called a "chargeback" to get the money back from the merchant-- if the merchant does not have adequate proof, it is pretty simple for the bank to get the money back.  If a merchant gets too many chargebacks, their merchant status is revoked and they can no longer use the Visa system.  Meanwhile your liability is zero.

If a malicious person has gotten your CC number, but nothing else, and that malicious person is not a Visa merchant, chances are he will not be able to do much with it, because, as stated earlier, merchants require the additional information to protect themselves.


According to the diagram on the NACL site, the NACL code runs with the same privileges as the renderer which is a reduced privilege process.

If NACL fails, an attacker can take over the renderer, giving them access to resources in the same renderer process (set of frames that could be in the same domain after some set of document.domain sets).

"The Security Architecture of the Chromium Browser" by Barth, Jackson, Reis, et al. says

  Process Granularity. Roughly speaking, Chromium uses a separate instance of the rendering engine for each tab that displays content from the web, ...

It would take a double hull breach to get more privileges than the renderer process.

But the render process has significant authority.

Even though an attacker cannot be able to tamper with other tabs, they can probably tamper with websites in the current tab, including possibly simulating events to load other domains into the owned tab.  As long as a renderer can cause page transitions, owning any renderer allows you to craft credential (cookie) carrying requests to any domain.  This opens all the same holes as XSRF, but possibly with the ability to keylog if the user interacts with the resulting page.


Is there any way to restrict multiple access to my server at the same time using one client certificate?

I'm not 100% if this can be done from the webserver layer, but your application itself can verify who is logged in.

Using PHP, this can be done using the following $_SERVER vars.  For example - in PHP-; using $_SERVER["SSL_CLIENT_S_DN_Email"], your application can determine if a particular user's email address (or SSL_CLIENT_M_SERIAL for the cert's serial number) is logged in already and take action (deny access, raise warning, ...) if a new "session" is initiated.  You'd need to keep track whether a user is "still logged in" though, usually through a timeout on last HTTP request.

Hope this helps,


Why using the premaster secret directly would be vulnerable to replay attack?

I think you misunderstand what a replay attack is. You are correct that a MitM wouldn't be able to see the premaster secret, but an attacker can still cause trouble even if they can't decrypt anything.

Say you make a request to the server ordering a widget. There's a MitM between you and the server, but the request is perfectly secure, and they can't decrypt anything. Unfortunately, this is an alternate universe where the premaster secret is used directly.

The MitM sees you've made a request to store.example.com. They can't see what the request is, but they can see that it's to store.example.com (either due to the IP address or due to SNI). They can't see any of the decrypted communications, but they can see all of the encrypted traffic. Just for the fun of it, they take all the encrypted traffic you sent to the server, and they send it again, 10 times.

Now your card is charged 10 more times and a few days later you end up with 11 widgets instead of 1.

Now what would happen if an attacker tried that in our universe? (very simplified)

The attacker sends a copy of the victim's traffic that it had saved
In the Server Hello, the server replies with a different ServerHello.random
All values the attacker sends that are based on the original ServerHello.random won't match
When the server receives the Finished message and tries to verify it, it will fail, because the master secret calculated by the server is different (even though the premaster secret is the same)
The server will abort the connection

The key point here is that there is some state on the server, the ServerHello.random, that is different for each connection, and the master secret depends on this state.


For most intents and purposes, its good to think of an API Key as a username/password combination.  The reason it's generally frowned upon to store API keys in the database in a reversible format is because if your database gets breached, it's possible for an attacker to gain access to all of the API keys which are stored in the application, and impersonate other users.

Showing users their API keys in plain text is essentially the same as showing them their passwords in plain text.  A more secure alternative might be just allowing them to reset their API keys, and not showing them what the original key was.


As part of the handshake for mutual auth SSL, both the server and the client have to prove that they hold the private key corresponding to their cert. If that isn't the case, the SSL handshake will fail. I think that is option (1) of your question.


Is it safe to use a stateless authorization mechanism where the clear password is stored on the keychain?

This is a well-asked question, and as the question itself lays out, even experts will have different opinions in the context of absolute/abstract framings of safety.

The nuanced reality of course is that there is no "absolutely safe," only varying degrees of unsafe, ranges of which may be more or less appropriate in any given specific situation.

In the absence of additional information, some starting point questions to help brainstorming/threat modeling:

What data do these credentials protect?

At one end of the spectrum, the app could be a game, the credentials protecting non-sensitive game state. On the other end, credentials could be protecting sensitive medical information.
Who are your users?

Are your users unsophisticated folks who may use the same password across many services, including your own?

Might your users be members of an identifiable group that may be more or less subject to having their devices compromised/searched/cloned (e.g. journalists, high level corporate staffers)?
What might happen to individual users and your community as a result of a compromise?

Can an actor who compromises one user's account under this app compromise other users, or steal money, or perform some other permanent, expensive damage?

You get the idea.

The one additional thought is that a password is fundamentally an especially powerful credential that is expected to work anywhere from any device at any time.

One alternative to storing the password on the device is to generate a long term, device-specific token, to be saved on the device instead of the password, and used to re-authenticate only from that device. This token doesn't have to be a single use "refresh" token- sometimes applications hash the password some large number of times and use that.

Certainly support for any additional authentication scheme requires additional complexity. Circumstances can help determine whether it's worth it. In more sophisticated situations, compromise scenarios can have likelihood estimations, and loss estimates, along with development, maintenance and support cost ranges, and Monte Carlo methods can be used to help improve the intuition on whether individual bits of complexity offer protections- by reducing risk and loss- that may be worth the long term costs.

Good luck!


using html5 websockets to bypass firewall TCP policy

First, websocket connections are initialized from javascript which gets executed by the web browser on the client. That means typical websocket connections are outbound connections, not inbound connections. Inbound websocket connections would only be possible when the host runs a websocket server. A normal browser will usually not do this. And even when the host runs a websocket server for some reason: a properly configured firewall in a usual client network, can, should and will prevent this.

Second, websockets are not normal TCP sockets. They use a custom framing protocol on top of TCP. That means that a websocket connection can only be opened to a service which understands the websocket protocol. So even though the websocket API can be used to make the user (try to) connect to any remote host, they will be unable to make them use any service not intended for use via websockets.

Third, this is not a "remote TCP shell", because the websocket only lives in the javascript engine of the web browser and in the context of the currently visited HTML document. It does not give the website the user is visiting any more rights to do stuff on the local machine than it wouldn't already have. Sure, it gives the javascript application the ability to communicate with remote servers, but there were already plenty of ways to do this, like AJAX.

So what possible abuse potential remains?

As an owner of a malicious website I could spread a javascript which makes the user connect to a websocket server and performs some malicious activity on it. I could use this to turn my visitors into spam zombies to spam some websocket-based application by someone else. But websocket has a build-in feature to protect against this. The users webbrowser sends the URL of the website with every websocket connection. That means a service can easily ignore any connections which do not originate from a known URL.

For further information, I recommend the RFC-6455 which describes the protocol itself and the W3C standard for the Javascript API in web browsers.


In the following articles, the decryption key of the decryption loop is mutated:

https://n1ps.wordpress.com/2008/09/14/w32virut-analysis/
https://n1ps.wordpress.com/2008/09/16/w32virut-analysis-part-2/

There's no universal guide to find all these kinds of mutations with OllyDbg or other tools but you could try to find Crypto code where there're lots of arithmetic/logic instructions as a tip to start your mutation digging journey.


Are there lists of most common words or ngrams used in passwords and passphrases?

Oh, there are a few places that show the most common passwords as determined through website breaches. Some examples:

http://blogs.wsj.com/digits/2010/12/13/the-top-50-gawker-media-passwords/
http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time
http://blog.jimmyr.com/Password_analysis_of_databases_that_were_hacked_28_2009.php

No matter where you look, it seems that 123456 is the password to beat. For all those above and more, start with http://www.google.com/search?q=list+of+most+common+passwords


Secure CDN content for a multi-tenant application

This really depends on your CDN. Most would minimally check the referrer and some would support single-use or restricted URLs (e.g. only available to a certain IP, time range, etc.).

Check any hot-link prevention documentation of the CDN or ask their technical support for options.

However, for any content, somebody can always download it and reshare it, so if you want maximum protection, you'll have to use some DRM.


Can a computer/MacBook be compromised/infected/hacker simply be requesting/attempt to join a network?

You do not have to worry, because you didn't send anything to the router that was part of the WiFi network you accidentally clicked on.

When any computer, regardless if it is a Mac, Windows, Linux, System V, ect., scans for available WiFi networks, it in fact is not scanning or communicating.  In fact it is just waiting for what is called "Beacon Signal", which WiFi routers send out at regular intervals.

The beacon signals are frames that usually contain information about the WiFi network.  These frames have many different types of information, and thus is said to be divided into many multiple fields.  To not go into to much detail here, out of the 10 most known fields I will explain in a very high level about only two of the fields.  These two fields are named "Capability Information" and "SSID" fields.

The "SSID" field is most known for containing the information relating to the name of the WiFi network.  This is how one is able to see the names of the networks, on the list of available WiFi networks.

The "Capability Information" field is sub-divided into further sub-fields, and it is this field that relates to your question.  The "Capability Field" contains information regarding the encryption, the type of WiFi network (IEEE 802.11 a/ax/n/b/g/.. standard), but more importantly relating to your question, whether the network requires a password or not to connect to it.

As long as you do not type in a password and hit enter, nothing is sent to the router that is sending out the beacon signals.  Basically no information from your Mac Laptop was ever sent to that WiFi network that you accidentally selected.

I referred to the IEEE Std 80.211 Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.


SMEP is activated by bit 20 of control register CR4 while SMAP is bit 21. Disabling it can therefore be done, at least, by patching the kernel code in order to remove the setting of this bit.

The relevant code seems to be in file arch/x86/kernel/cpu/common.c, around line 269:

    if (cpu_has(c, X86_FEATURE_SMEP))
            set_in_cr4(X86_CR4_SMEP);

Just comment that out, recompile, reboot. (I have not tested it.)


How to minimize the risk posed by Intel AMT/ME's "ring -3 exploits"?

At the end of the day, there is nothing that you can do with the iCore5.
It has a permanent backdoor that has total access to and control over the rest of the PC.
If knowing this fact bothers you, then you can only really do one of two things:

Turn back now and refocus your mental energy on thinking happier thoughts.
Dig deeper and develop a newfound appreciation for the GM45 chipset and 'obsolete' ThinkPads.

The fastest and most capable PCs with removable ME are ThinkPad models X200, T400 and T500. These can be completely rid of Intel's ME in a relatively straightforward procedure that only requires a beagle bone black, an old ATX PSU, a Pomona 5252(works with either the SOIC-8 or the SOIC-16) and some jumper wires.

Alternatively, you can purchase one of the aforementioned ThinkPads with the ME removed for you, albeit at a massively increased cost.


As a professor, he has surely access already to most of the personal information you may provide in a CV. So I do not see any problem inherent to identity theft.

Linkedin is an example where you can read the careers of known and unknown people to you.

However, in general, an attacker may use personal information for some social engineer procedure to get something (may be just information) illegally. Also, if you are American, writing your birthday on your CV (many do it) is a a bad thing (How dangerous is it to reveal your date of birth, and why?).

But coming back to your professor, he has nothing nefarious to do with your CV as most of information provided in it is already in his hands since the first day he started to teach you.


Full disclosure, I'm a Solutions Architect for Authy and am pretty familiar with our product. :)

First off, absolutely DO NOT turn off 2FA!  The real use-case you're preventing with 2FA is someone compromising the website's database and running off with the login/password combination.  Always use 2FA!

With 2FA enabled, you are also notified that someone is trying to login and you can subsequently deny them access.  If you turn off 2FA, you 1) won't be notified and 2) won't be able to deny them access.

Regarding your syncing concerns let me reassure that we've thought about a lot of these issues and have a solid technical solution.

First off, syncing is opt-in (as you've noticed).  Secondly, the Authy OTP seeds between each of these devices ARE DIFFERENT.  Here is a side-by-side image of the Authy Desktop app and the Authy iPhone app.  Notice the values are different!

Google Authenticator seeds which are stored in Authy will be the same as they have only a single seed value which needs to be stored and shared.  This is a limitation of the Google Authenticator approach.  These seed values are encrypted via your backup password.

If your phone is lost or stolen, you can disable that device's access via any of your other devices.

For more information on the security around Authy's multi-device support, check out this Q/A exchange:  Authy - is my backup secured by only my password or 2FA s well

Hope this helps!  Let me know if you have any more questions.

Cheers,
- Josh @ Authy

p.s.  I use 1Password as well and use a pretty gnarly password for backup & sync.


Can FB messenger video calls be intercepted?

All the communications done over Facebook Messenger are encrypted but that does not mean that one cannot sniff the packets. One can easily sniff the packets but the bad guy won't get to know anything as everything will be encrypted (unless the encryption is broken).

As far as Facebook recording the conversation is concerned, it's a complete NO for that. Facebook only keeps the logs of the when the conversation happened, with whom and duration.

You can also read their Messenger policy for more info.


How to limit your stored XSS payload to only target certain people?

An XSS vulnerability that lets you run arbitrary JS lets you do anything you can do with JS. So designing your payload is simply a programming issue.

If you want to limit on IP, just check the users IP. If you want to limit on logged in username or id, just grab that from wherever it is stored and compare to your targets. Usernames are usually displayed somewhere on the page, and if it's not just fetch a page where it is displayed and read it from there. Especially for a SPA the username is probably stored in a JS variable so you don't even have to grab it from the DOM.

It might require some searching to find where to retrieve the info from in your specific case - there is no universal solution - but it should be doable with a little bit of JS.


Risks of using a webpage without SSL/TLS for donations

If there is no HTTPS on the pages that redirects to Qgiv, a Man-In-The-Middle could intercept the redirection page and replace the redirect to Qgiv with a redirection to the attacker's site.

The attacker's site might use HTTPS and will capture the card details as the user will be unaware whether the site is the legitimate payment gateway or not.

Of course, the attacker will need to be suitably placed, e.g. in a coffee shop on an insecure wireless network. It is recommended to use HTTPS on the whole site to prevent this, in combination with an HSTS policy.


Can a WAF block or detect crafted html file and obfuscated PHP script/shell

It all depends on the WAF configuration and the WAF technology. As several web applications have upload features by nature (for example, to upload your CV in a recruitment website), the WAF need to be tuned to ensure only the file types you want are being uploaded. I've seen a lot of system administrators just disabling the file check option instead of fine tuning it, leaving the application vulnerable to malicious file upload.

Most of the WAF solutions are signature based, meaning that if the attacker code it's own reverse shell file or do a very good obfuscation job, probably the WAF will not detect it. For this reason, it is important to not trust only on the WAF, but also adopt secure coding.

If you really need to have file upload features on your website I do recommend you checking this guide which explains how to properly code your application.


Securing data passed between two sites via a browser

I need to pass some data securely

What do you mean exactly by "securely", do you mean that:

You do not want the user to be able to read the content of the protected data (ie. you want to ensure the data confidentiality),
You do not want the user to be able to tamper or forge the data (ie. you want to ensure the data integrity)?

By simply encrypting the data, you solely ensure the data confidentiality. Without knowing the key, a malicious user could still try to modify the encrypted data to try, for instance, to get access to another user's data.

If you want to ensure the data integrity, you do not need asymmetric signatures (it would work, but as you feel it would be overkill), what you need is to apply an HMAC to the data. Thanks to this, given a common secret, website B will be able to check that the data allegedly received from website A is indeed authentic.

From then the fact that you want to apply a cryptographic function on top of this to hide the data content is totally up to you. The data could perfectly stay in clear form without reducing the security of the HMAC as an integrity protection system.


what are security flaws on providing access to users through a unlisted/private/token/signed URL?

As long as you are not giving access to any information and only allowing for input, there isn't really a downside, but there also really isn't a need.  What are you gaining by sending such a link?  You know nothing more about the user than you did if they just went to your website (other than perhaps that they do have access (either legit or not) to whatever communication mechanism you sent the link to.

This could be done before or after the information is entered and as long as no information is revealed, there is really no apparent security issue since all someone could do is convince you that someone else is actually someone that they aren't if the person they are pretending to be decides to go along with it.

You simply have to make sure that the token is random enough that it can't be guessed by an attacker.  One possible way to do this is use two pieces of information and implement a lock out if too many tokens are tried for a given identifier.


Malicious vbs script only opens a GET HTTPS connection

As far as I can tell, your assessment seems accurate.  I see 2 possible options:

This is a reconnaissance probe to see if someone will open the attachments.
This attack was poorly executed, and you were sent an unfinished script.

I'm currently leaning towards the second explanation.  There is no reason to echo any output in a dropper, let alone something as suspicious as "Installation completed."


This application is not using CSRF token but they are still able to protect sensitive actions on the site

How the question, is there any way to still bypass this way implementation?

As you've already said, it is a good protection against CSRF since the Authorization header is a) unknown and b) is not sent cross-origin.
These properties are no longer true though if the attacker finds a XSS in the original site, since then it might be either possible to extract the Authorization information or to misuse existing code in the site to send requests controlled by the attacker but same-origin. But XSS is also a problem with classic CSRF protection, so this is not a new attack vector specific for this kind of protection.


Why do I need two parameters in an HTTP parameter pollution attack?

The idea would be that different parts of the server code interpret the request in different ways, resulting in an application that is vulnerable to HTTP Parameter Pollution.

For your example /editpost/?postuid=19348&postuid=1 the query string would be parsed differently for the code parts that carry out authorization (those would have to check for authorization on postuid=19348) and actual editing (those would have to edit for postuid=1).

This isn't a regular problem in modern web applications because parameter parsing is done by the framework usually, in (modern versions of) php for example, $_GET["postuid"] would contain the same value for both code fragments, making a HTTP PP attack useless.

HTTP PP used to be a big problem (and still is, whenever this is the case) when parameters are parsed "by hand", i.e. on the application logic layer. That opens the door for different people implementing this parsing differently.


Do I need to hash or encrypt API keys before storing them in a database?

Yes, you should absolutely hash your API keys. In effect, they are your passwords and should be treated as such. And note that's hashed - not encrypted. You never need to decrypt the API keys, hence you should not be able to.

As saghaulor says, you need to make sure you use a version 4 UUID (a random one, that is) and that you use a cryptographically secure source of randomness when generating them. Since a correctly generated UUID contains 122 bits of entropy you need not worrie about salting or using a slow hash function like bcrypt. A single round of SHA-256 would be enough.

A problematic part of your design is that you are giving users "passwords" that are delivered by mail and that they can not change. That may not be good enough for security concious users. Perhaps the portal you mention will solve this problem.


Can I perform WEP cracking from several laptops against 1 AP

There are two stages in the classic WEP attacks:

Stage 1: gathering packets.  Traditionally, this is done by fake-authenticating with the target AP and then re-injecting ARP packets to get the AP to send packets quickly, but it can be done completely passively instead.  Trying to do this on multiple laptops at once can actually slow things down, as they interfere with each other's re-injections or the AP's transmissions.

Stage 2: analysis.  The captured packets are statistically analyzed to figure out the most likely value for the WEP key.  Since this is completely client-side, the computers can't interfere with each other.

In a classroom setting, I'd pick one student to perform the re-injection part of the attack, and have the rest of the students put their laptops into passive packet-gathering mode.


You don't.
Once someone has access to your SD card for prolonged amounts of time, it's not longer your SD card. This is a variation of one of the 10 immutable laws of security.


Testing network ACLs from blocked CIDR ranges

One simple way of testing your filters is to spoof a TCP SYN packet with one of the IPs black-listed.

Another way is to check the FW that AWS is offering if it has a simulation feature where you enter the desired packet information (Source IP, Source Port, Destination IP, Destination Port) and see what the firewall will do with it through its current configuration.

In regard to the validity of the offered lists that is not something i can comment since i do not know where AWS is obtaining these lists.

Hope this helps


Chrome vs Explorer - how to explain in plain words that open-source is better?

Open source software is not necessarily better or more secure.

Where open source has an advantage is the potential for independant security minded individuals to examine the source code and hopefully the conceptual model for a given software project. This advantage is contingent on:

review by qualified individuals
feedback from the reviewer to the project about potential weaknesses or vulnerabilities in the source code, algorithms, and procedures
the project fixing the reported weaknesses and vulnerabilities
the project becoming better educated as to what makes software more secure

Given enough itterations of the above, any software, not just open source becomes more secure than the average.  Many closed source companies perform software security reviews. Some even bring in third parties to ensure indepent and objective reports. A project providing open source allows a wide audience to review any part of the software bringing transparancy to the review process and the software implementation. The difference with most closed source programs is that the process and implementation is inaccessible to the users. A user can not determine whether a piece of closed source software has been security reviewed. And in most cases a user can not determine whether a piece of open source software has been security reviewed. The only difference is that, given a capable enough user, that user can check on the status of the open source process, but they can not check on the status of the closed source process.