There's a few problems with your configuration as it stands, and some other concerns which should be addressed regarding setting up a pentesting lab in a shared network environment.

Firstly, only systems with a Bridged or NAT adapter will be able to communicate with anything beyond the VM network and/or host system.  A quick summary of common VirtualBox networking modes will help explain this:

Internal Network:  One of the most restrictive networking configurations, this will only allow communication among guest systems in the Internal Network of the same name.
Host-Only Adapter:  The other most restrictive configuration, this will only allow communication between the guest and its host.
NAT:  This is the most controlled means by which you can allow the guest systems to communicate beyond the host.  In this configuration, the host system acts as a NAT router between the external network and the guest systems' network.  All guest systems using this configuration should be able to communicate with each other and the host, as well as any external systems.  However, port forwarding will be needed if you wish to expose some services of the guest systems to external systems.
Bridged:  This configuration joins the guest computers to the external network as if they were completely separate systems.  It allows the most seamless possible communication between the guests and the outside network.  The guest systems should be able to communicate with the Internet and other systems on the external network, just as easily as those systems already communicate with each other.

You can read more about these networking modes, and more, in the VirtualBox manual under chapter 6:  http://www.virtualbox.org/manual/ch06.html#networkingmodes

Your second problem, I'm presuming, is with your IP configurations.  Assuming that all of your systems are configured to use the default subnet masks for the IPs they've been configured on, all of your systems are effectively on three different networks.  Without a router or two between them, or a different subnet mask configuration, they will not be able to communicate with each other.  To understand this better, you'll need to read up on some materials covering basic network routing and switching.

All you really need to understand, so that these devices can communicate with each other and the outside, is that every 255 in the subnet mask represents a portion of the system's IP which must match the IPs of other systems which are to be considered part of the local network.  The zeroes in the subnet mask represent portions of the IP which are used to uniquely identify systems on the local network.  You should try to learn much more about networking before exercising this knowledge though, and especially before attempting to conduct any sort of penetration testing exercises on a system connected to a network you do not own.

So, in order to get your guests to communicate with other systems, including each other and the outside world, you need two things:

A compatible guest network adapter configuration.
A properly configured IP address and subnet mask.

For local network communications, the IP address and subnet mask must be compatible with those of the target systems.
For Internet communications, the IP address and subnet mask must be compatible with the router providing the Internet link.  The system will also need to be told the IP of that router (configured as the "gateway"), and appropriate DNS servers.

Having covered this, there is another issue that should be addressed.

Penetration testing and network monitoring are very sensitive activities which should not ever be performed on a network where they are not authorized.  Your university's network would most likely, to you, be one such network.  Therefore, you should be very mindful to not conduct these activities while your guest systems are connected to the external network.

Before enabling any Bridged or NAT adapters - and, for your host system's protection, any Host-Only adapters - make sure that all software and services used for your penetration testing or network monitoring exercises have been stopped and/or disabled.
Only enable Bridged or NAT adapters when needed, to download new software or updates to the guest systems.  Disable those adapters after the need has been fulfilled.
Before performing any penetration testing exercises, or network monitoring, make sure that all Bridged or NAT adapters are disabled.  To avoid causing problems with your host system, you may also wish to disable any Host-Only adapters.

Again, before you do more in terms of penetration testing or network monitoring exercises, you should strive to gain a much better understanding of how computer networks work.


Polymorphic/Metamorphic malware is written on low-level or high-level languages?

Polymorphic/metamorphic is usually at least partially written in a low level language.

The purpose of polymorphic malware is to evade virus scanners.  It does so by making it hard to identify a signature for the file.  The simplest version, of course, is a loader which decrypts a section of code when it is time to run.  However, this has a limitation: the loader is now an easy signature to spot!

The solution is to write the loader in a polymorphic manner itself.  This is a sort of chicken and the egg problem.  However, we know the application EVENTUALLY gets compiled down to machine code, so polymorphic code developers will write machine code which can be mixed and mutated and still work.

This low level work is very hard to do in any language above assembly, because the higher level you go, the more of a signature you'll leave behind (high level languages were never written to avoid leaving signatures).

However, that doesn't mean the entire malware has to be low level.  Once you can make a poylmorphic malware that knows how to decrypt and encrypt code, it becomes possible to write the rest of the virus in a high level language, and just attach it to the low level polymorphic loader/encrypter/decrypter.

(And, of course, this battle will continue if the virus scanner looks at memory after decrypting, but I think just handling this "scan the file for signatures" Virus Scanner approach should get you going!)


Go to http://www.exploit-db.com/google-dorks/ . It is huge repository of Google Dorks . Add site:mysite.com at the end of each relevant dork as mentioned by Brain Adkins and voila you are good to go . A simple python/bash/ruby script to scrape dorks from that site ( for python  http scraping i love beautiful soup ) , append site:mysite.com at the end of relevant ones and its done .

Remember many dorks will not be relevant to your specific website .


Facebook API : App Secret - possible misuse

You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code.
Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a webservice, mobile/desktop clients use app secret key as a credential for server to validate that its the 'real' legitimate client app.

  If the evil guy obtains these entries, what is the worst possible misuse he could perform?

He could make a spoofed client that looks just like your client/application and release it. Unsuspecting users will download it and use it to connect to facebook. The fake app doesn't still get users credentials (which is good) because the authentication of user credentials happens on a facebook page. However, the user ends up authorizing this fake app on facebook. Facebook happily does that because it believes that anyone who presents that secret is you. As a result, the fake app gets the 'access token' for the user and can start posting comments and do other things that your real app doesn't intend to do.
So in a nutshell, its your reputational value that is at stake here. Other clients can impersonate as your client to facebook.

This is a thorough case study of one such twitter client which stored consumer key (their equivalent of app secret) in plain text.

I am quoting one line from that blog:

  It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.

Now, how do you protect the client secret?
If it is a standalone client (like a mobile app), you have little choice but to embed it in some form. Unfortunately for a expert reverse engineer, its only a matter of time before it can be decoded. After all its somewhere there (in some form) in the client. If the client can re-calculate/re-assemble it, so can a reverser.

Edit: If your application architecture permits it, your server can perform the OAuth steps on behalf of the client/mobile app. This way the key resides in the server, it does all the OAuth steps and passes the access_token to your client to use it to access user's facebook data. At this point you are doing something very similar to the browser - web server - facebook interaction described here. Just replace 'User's Browser' with your 'Client/Mobile App' and 'Your App' with 'Your Server' in that picture.

If this is some sort of a web application, this can be easily achieved by keep the key only on the server side and using facebook's server side flow to prevent app secret from leaking out.


How to check if you are navigating anonymously

You should look into TOR browser if you're looking to browse the web for the most part anonymously. It's a little more beginner friendly than tails.
To answer your question directly, yes, the easiest way to verify you are accessing the web via a TOR exit node is to go to google or DuckDuckGo and type 'whats is my IP' before then after you connect through TOR or Tails and confirm the IP has changed.


Cache-Control: private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.

Looking at OWASP: Testing for Browser Cache Weakness

  Browsers can store information for purposes of caching and history.
  Caching is used to improve performance, so that previously displayed
  information doesn't need to be downloaded again. History mechanisms
  are used for user convenience, so the user can see exactly what they
  saw at the time when the resource was retrieved. If sensitive
  information is displayed to the user (such as their address, credit
  card details, Social Security Number, or username), then this
  information could be stored for purposes of caching or history, and
  therefore retrievable through examining the browser's cache or by
  simply pressing the browser's "Back" button.

OWASP says that, preferably the Cache-Control is set to no-cache. With Cache-Control: private information might still be cached within the browser. This can be a security risk if your users tend to use shared computers. This is especially important for websites which send/display sensitive information such as credit card details.

Is it a security breach? no. Can it be a security risk? yes.

You should allign with the website's owner to see what kind of information is shown and stored and if the cache-control should be more restrictive.


OWASP ZAP: How to use TLS client certificate authentication?

You should be able to add any certificates that you need to use via the ZAP Options / Certificate screen (https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsCertificate).


should I encrypt a certificate used only for automation?

Your PEM file may contain Private key used in your build and tests. You should safekeep PEM properly.


How did I have two different public keys for one e-mail address

This assumes that the keys are in fact different. As the comments did already point out, there are pitfalls when comparing keys manually that can lead to the false conclusion they'd be different. Those include:

The two keys are differently encoded but hold the same information
You compare different hash types of the same key

Generally speaking, you can have a (finite, but for all practical considerations) unlimited number of key pairs. If Mailvelope instead of exporting your public key created a new key pair and exported that public key, you can decrypt both messages as you hold both private keys.

There also is a feature (I think Mailvelope does not support it) that is called sub keys, which are regular key pairs associated with your main key pair.


How much does TLS version matter when using the same cipher suite?

Protocol versions matter, even given the same cipher suite, because the suite specifies the primitives but not necessarily how they are to be used. For example, the critical difference between SSLv3 and TLS1.0 that makes the former vulnerable to POODLE is that TLS mandates validation of the padding, and SSLv3 does not. TLS 1.1 requires an explicit initialization vector (rather than the implicit IV used in TLS1.0 block ciphers), and changes how padding errors are handled; neither of these things are particular to any given ciphers.

Of course, just because a protocol requires something doesn't mean the implementer will do it correctly. Some network gear (like load balancers) was handling TLS1.0 connections but failing to validate the padding (in violation of the TLS spec, but not the SSL spec), making them also vulnerable to POODLE. Similarly, one of the things that made Heartbleed so bad was that OpenSSL allowed heartbeat messages to be sent before the handshake was completed, allowing an untrusted attacker to man-in-the-middle a connection and attack both sides during the handshake. (Of course, the buffer over-read at the core of Heartbleed was also an implementation failure, but the standard probably doesn't explicitly called out that you're supposed to only return the data that the other side sent you instead of arbitrary memory. It does specify when a heartbeat message is legal, though.)

Protocol versions can also add support for cipher suites. TLS 1.2 added support for authenticated encryption ciphers, enabling the addition of suites based on AES-GCM and AES-CCM. However, even if you're using the same cipher suites, you're more at risk when the protocol is older.

For more detail, you might want to ask on the Crypto SE. SSL/TLS is complicated and you may find people over there who can explain the relevant pieces more clearly.


I got it. Reset the machine and rewrote the code (find the address through gdb instead). It works now. Thanks everyone.


Different SSL cert behavior with Chrome on desktop vs. Chrome on iOS

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=46.137.89.126

https://www.ssllabs.com/ssltest/analyze.html?d=uk.care.com&s=54.228.236.90

The padlock is yellow because you have a certificate that uses SHA-1 in the certificate chain and Google have declared war on SHA-1 certificates.

Chrome uses the operating system's root CAs. If the operating system has the "GeoTrust Global CA" certificate with fingerprint de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, then there won't be SHA-1 certificates in the chain, because your cert can be linked to a cert the browser trusts using only certs that use SHA-256.

But if it doesn't, the chain will use the older "GeoTrust Global CA" with fingerprint 7359755c6df9a0abc3060bce369564c8ec4542a3, which is sent by your server and uses SHA-1, to link your certificate to a certificate trusted by the operating system (an old RSA 1024 cert).

You can try not sending the 7359755c6df9a0abc3060bce369564c8ec4542a3 certificate and see whether it breaks any clients you care about (those that don't have de28f4a4ffe5b92fa3c503d1a349a7f9962a8212 in their trusted certificate list).

Also, you should:

Upgrade your openssl and web server to use 2048 bit DHE (unless you need compatibility with older java clients).
Even if you can't upgrade to 2048 bit DHE, generate new DH params. You're using a common prime number that is the one would be broken first by anyone who can factor 1024 bit numbers.
Reorder the priority of cipher suites: ECDHE+GCM first, ECDHE+CBC second, DHE+CBC third, RSA+3DES fallback last.

EDIT: A very good explanation for two corner cases when you send SHA-2 chain and the browser still sees SHA-1: https://sslmate.com/blog/post/chrome_cached_sha1_chains


Windows certificate store suddenly changed security level of one of my certificates

Security levels on private keys in Windows are a rather complex subject; in particular, there are options for activating or deactivating the password, and for caching the password in memory. See this blog post for an introduction. Notably, the protection level for a given key is not intrinsically immutable; it may be changed. Possibly, Windows 8.1 changed some default behaviour; or maybe some action on your part, that you do not remember (that's not a blame; there are way too many popups in Windows to realistically expect to remember them all and miss none), changed the protection level at a time which fortuitously happened to be after your last pre-8.1 backup. In any case, you could go inspect the current status of your private keys and change it according to your wishes.


Multiple SSL connections in a single HTTPS web request

When you connect to an HTTPS Web site which uses a "problematic certificate" (e.g. one which is not issued by a recognized CA, an expired certificate, or a certificate which does not contain the server name as it appears in the URL), the browser asks for confirmation from the user. This can happen only after the server certificate has been retrieved, as part of a SSL handshake. This accounts for at least one initial connection with handshake.

Keeping a SSL connection open uses up some resources on the server; so servers auto-close connections after some inactivity, and browsers try not to keep connections open for too long. Displaying the warning about the invalid certificate implies waiting for the human user to come to a decision (to click or not to click, that is the question). This will take some time; humans are slow. Therefore, the browser will first close its initial SSL connection, the one it used to obtain the server certificate -- not HTTP has occurred yet, though, only the SSL handshake. When the human user finally decides to connect despite the scary warning, the browser will open a new connection, with a new SSL handshake, and in that one there will be some HTTP (as "application data").

As for the other connection (the "initial connection" is actually two connections made in parallel): Chrome is known to open speculative connections so as to speed up subsequent requests; in general, a Web page includes images which will have to be downloaded promptly. Chrome appears to be overzealous at times. The plausible scenario is then:

Chrome opens two connections with SSL handshakes.
Chrome notices that the certificate is flaky, and requires human intervention. It closes the two connections without doing any HTTP within the SSL tunnels.
When the user decides to open the page, Chrome opens a third connection, does a SSL handshake, and this time follows on with the HTTP dialog.


Do VPNs really mask your identity or is it a facade?

Is it reasonable to say, any server that I request data from, regardless if I am behind tor, VPN, ect, can in fact, find my source IP contained within the header of the Datagram, and thus, know the true origin of the request.

No on IPv4. A virtual private network works by connecting, between you and the VPN provider, a tunnel such that you can route through a private network - one of the 10.0.0.0/8, 192.168.0.0/24 or 172.16.0.0/16 address spaces. This is why it is a "private network". The virtual bit comes from the fact you are actually routing over the public internet.

Your access to the internet is then "proxied" like a home router i.e. network address translation. Since there is no route to a private IP address, unlike a public one, the public facing router must take responsibility for both forwarding packets out to the internet and tracking where the replies should go to.

One way to do this is via source ports, but it is not the only way. In this case the source port of the packet and hence the port on which replies are received tells the router which private network host to send the packet to.

As such, you will "appear" to have the IP of the exit gateway of the VPN to servers that see your requests.

Tor circuits, simplified, are like the gateway process times 3. Each step knows who to send on to and who to return to, but not anything else, with each taking responsibility for routing. So, between you and the internet you have a tor entry server, a relay server and a tor exit node. The relay server for example knows to relay packets from the entry server to the exit node, but no more - it does not know the eventual destination of the packet which only the exit will know, or the source, which only the entry knows.

This is completely opposed to conventional routing, which on the public internet explcitly has a source and destination IP. Routers do not re-write this, instead they simply try to calculate the most efficient "next hop" (directly connected hardware to which they can send the packet). Multiple such steps happen in a typical internet communication (see traceroute) and since tor nodes are internet communications tor nodes packets will also hop over multiple nodes taking varied routes through the internet with known source and destination (which are crucially only the relays).

I've written a lot of text, so perhaps it's worth recapping with steps what happens to a packet in the VPN scenario. Let's say I'm sending a HTTP get request.

I connect to VPN. The process of doing this preserves my route for VPN traffic but otherwise creates a default route via the VPN gateway and makes me part of their private network. Examples from my VPN provider:

$ ifconfig
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.0.9.14  netmask 255.255.255.255  destination 10.0.9.13
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
    RX packets 48  bytes 23132 (22.5 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 55  bytes 12215 (11.9 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ ip -4 route
0.0.0.0/1 via 10.0.9.13 dev tun0
default via 10.0.0.1 dev wlp2s0  proto static  metric 1024
10.0.0.0/16 dev wlp2s0  proto kernel  scope link  src 10.0.0.109
10.0.9.1 via 10.0.9.13 dev tun0
10.0.9.13 dev tun0  proto kernel  scope link  src 10.0.9.14
notareal.ip.200.165 via 10.0.0.1 dev wlp2s0
128.0.0.0/1 via 10.0.9.13 dev tun0

if you look at this carefully you'll notice some strangeness. The default route remeains in place but has its metric set high (low priority) whereas 0.0.0.0/1 and 128.0.0.0/1 - comprising all IPv4 except the notareal.ip line - are sent via tun0. That line exists so that VPN traffic can still go via the proper original interface.
I craft a packet and send it. According to my above mentioned scheme, when I say I want to send this packet to stackexchange.com my routing table instructs me to forward it to the VPN gateway because that's the highest priority matching route.
Internally, the VPN software does its crypto thing and writes a packet to the VPN gateway. This too is looked up in the routing table and goes via the actual network. It is unwrapped at the other end.
At the other end, the packet hits the gateway and is NAT'd, or proxied, or whatever scheme your provider uses. They then leave for the public internet.
When a reply comes in over an established TCP connection, the reverse process happens.
UDP is connectionless anyway; inbound UDP and outside initiated TCP connections are not possible because there's no public routes to me.

In essence, this is quite like your home network NAT, except virtual.

I am using OpenVPN in this case; what you see if you try these steps depends on your provider, VPN software etc and are essentially the same.

Now to answer your question "do VPNs really mask your identity?" - well, there are a lot of ifs and buts and ummms to that, but here's the simplest breakdown I can think of:

If you are an server operator and someone is using a VPN, it's unlikely you'll be able to identify them. You'll see traffic from the VPN provider easily enough, but you won't know who it came from originally unless:
You are a server operator with some kind of authentication mechanism or the ability to store persistent "tracking" cookies on the target. In the former case, you might even know who they are; in the latter case you know they are a unique individual and you won't know exactly who. However:
The VPN provider sees all - the DNS requests you make, where your packets are going etc. In this sense they are now your ISP. Even if you paid them anonymously and gave them details to a completely segregated persona, they still know where your packets come from. The upshot of this is that there is a link to your true identity, or at least whoeever pays the internet bill.

Thus, if you give law enforcement sufficient motive, they'll find you easily enough.

IPv6 is an interesting area. I don't know many people who routinely route ipv6 over VPN mostly because the only person I can name with IPv6 connectivity is me... but, it can be done. IPv6 does not have the concept of private address spaces (slight lie, they do exist) as everything is supposed to be world-routable. Indeed some people believe that NAT breaks the original conceptual design of the internet as a single globally routable network.

Anyway, you can read more about it here - you get IPv6 routable blocks assigned to you instead of private ranges.

If you're wondering, though, publicly routable doesn't necessarily mean packets will be accepted, it just means they could be directed there. There can still be firewalls blocking all incoming connections.

Edit: as an interesting educational exercise, try listening for traffic with wireshark on the VPN interface (in my case tun0) versus the actual hardware interface :)


How to contact Microsoft regarding security flaw?

According to https://hackerone.com/bing

If you have found a security vulnerability in any of Microsoft’s
online services, please send e-mail to secure@microsoft.com. We will
respond to your submission within 24 hours and start working right
away to remediate the vulnerability. To help our engineers identify
the potential vulnerability, please include as much information in
your report as possible. For example, include the following:

Proof-of-concept and/or URL demonstrating the vulnerability
Type of issue (cross-site scripting, buffer overflow, SQL injection, etc.)
Any special configuration required to reproduce the issue
Impact of the issue, including how an attacker could exploit the issue

To encrypt your message to our PGP key, please go to the Microsoft
Security Response Center PGP Key and S/MIME Certificate page for
further information.
Please note that the Microsoft Security Response Center does not
provide technical support for Microsoft products. If you need
assistance with something other than reporting a possible security
vulnerability, please see the statement below that most closely
matches your situation and expand the statement for next steps.


Most widely used non Cryptographic random number generators

Mersenne Twister is a non-cryptographic RNG that's commonly used in many applications. According to Wikipedia:

  The Mersenne Twister is the default PRNG for the following software systems:

  Microsoft Visual C++,[3] Microsoft Excel,[4] GAUSS,[5] GLib,[6] GNU Multiple Precision Arithmetic Library,[7] GNU Octave,[8] GNU Scientific Library,[9] gretl,[10] IDL,[11] Julia,[12] CMU Common Lisp,[13] Embeddable Common Lisp,[14] Steel Bank Common Lisp,[15] Maple,[16] MATLAB,[17] Free Pascal,[18] PHP,[19] Python,[20][21] R,[22] Ruby,[23] SageMath,[24] Scilab,[25] Stata.[26] It is also available in Apache Commons,[27] in standard C++ (since C++11),[28][29] and in Mathematica.[30] Add-on implementations are provided in many program libraries, including the Boost C++ Libraries,[31] the CUDA Library,[32] and the NAG Numerical Library.[33]

Mersenne Twister is a very good PRNG, with good statistical properties, very long period, and is fast. Despite being a very good PRNG, and is widely used for many games, statistical simulations, and other purposes, it's not suitable for cryptography.

Another common RNG is linear congruential generator (LCG), which for a long time is the default RNG in popular C libraries (and many other languages that uses C library, such as PHP). LCG is a simple but very poor RNG, even for non-cryptographic RNG standards. Its period size is embarrassingly small, already-produced numbers cannot repeat for the entire period, and it has statistical properties that makes it unsuitable for many purposes.


No, it's not (assuming you aren't on google.com, as indeed you aren't in that screenshot). However, depending on the way the browser works, there are a few things that could be going on here:

The browser might not actually block all third-party cookies, just ones you haven't visited. This is the default behavior in some browsers, like Safari. Since you've presumably visited google.com, it would be trusted.
The browser might only be blocking new/updated third-party cookies, and not prevented from sending existing ones (that haven't expired) from before that setting was applied.
The browser might be reporting all the cookies it has for all pages with content on the page, but not actually sending the third-party cookies. That's weird, but hardly the weirdest thing I've seen browsers do.
The browser might automatically trust certain domains. Chromium is made by Google, after all, even if Microsoft then wraps it up in their own little-c chrome.
The browser might have been explicitly configured to trust google. It's widely used and trusted, including for single sign-on, and potentially you or somebody else acknowledged the value to allow it on third-party sites.

There are probably more options; those are just the ones that seem most likely to me.


how can an attacker use a fake temp file to compromise a program?

The first thing to consider is what is the purpose of the temp file.

If the temp is outputting useful information, an attacker could use this to glean information about the functionality of the programs, settings, error messages, etc (depending on the output). The attacker may be able to have a malicious program occasionally scan such files looking for certain patterns to then use in attack logic.

At the same time, if the temp file is going to be read in, you can change the input logic of the legitimate program which is not tightly locked down. For example, if the temp file is going to be read in for the purposes of eval() or running a system() execution you can then make the program do something its privileges will allow on the system to do, that are not expected.

Instead of modifying the temp file which will be read in, it may be possible to create a symbolic link to another file that you as a user cannot access but that the application may have privileges to read. If the program prints out the temp file, you could expose it that way. It sounds like the attack being described in a privilege escalation, not a direct change to the password file.

Code Project: Security Tips for Temporary File Usage in Applications

  If the attacker knows where the application creates its temporary
  files and can guess the name of the next temporary file, the following
  attack can be realized:

  Attacker will put a symbolic link at the temporary file location.
  The attacker will link the symbolic link to a privileged file.
  Now, the application will unknowingly write to the privileged file instead of writing to the file in the temp directory.

There is also a CWE (CWE-377: Insecure Temporary File) for this, worth the read as well as some of the related instances:

  If an attacker pre-creates the file with relaxed access permissions,
  then data stored in the temporary file by the application may be
  accessed, modified or corrupted by an attacker. On Unix based systems
  an even more insidious attack is possible if the attacker pre-creates
  the file as a link to another important file. Then, if the application
  truncates or writes data to the file, it may unwittingly perform
  damaging operations for the attacker. This is an especially serious
  threat if the program operates with elevated permissions.


Creating a simple self-signed crlertificate with openssl x509/ca/req

As far as I understand you looking for something like:

configuration file: openssl.cfg

# use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = custom_ca

[ custom_ca ]
dir             = ./demoCA
serial          = $dir/serial     #  a text file containing the next serial number to use in hex. Mandatory.
                                 #  This file must be present and contain a valid serial number.

database        = $dir/index.txt # the text database file to use. Mandatory. This file must be present though
new_certs_dir   = $dir/newcerts  # specifies the directory where new certificates will be placed. Mandatory.
certificate     = ./ca.crt       # the file containing the CA certificate. Mandatory
private_key     = ./ca.key       # the file contaning the CA private key. Mandatory
default_days    = 365            # how long to certify for
default_md      = sha256         # the message digest algorithm. Remember to not use MD5
policy          = custom_policy  # a section with a set of variables corresponding to DN fields

[ custom_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName         = match     # C
stateOrProvinceName = match     # ST
localityName        = match     # L

-

$ openssl req -nodes -newkey rsa:2048 -keyout ca.key -out ca.csr -subj "/C=US/ST=California/L=Los Angeles"
$ openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
$ openssl req -nodes -newkey rsa:2048 -keyout new_server.key -out new_server.csr -subj "/C=US/ST=California/L=Los Angeles"

$ mkdir ./demoCA
$ mkdir ./demoCA/newcerts
$ > ./demoCA/index.txt
$ echo 00 > ./demoCA/serial

$ openssl ca -config ./openssl.cfg -out new_server.crt -startdate 00000101000000Z -enddate 99991231235959Z -cert ca.crt -keyfile ca.key -infiles new_server.csr

If you have a segmentation fault 11, you need to change the index.txt.attr from unique_subject = yes to unique_subject = no:

$ cat demoCA/index.txt.attr
unique_subject = no

$ openssl req -text -noout -in ca.csr
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=California, L=Los Angeles
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a8:d7:f8:b3:3c:66:7d:ca:2d:fc:05:ea:93:2b:
                    ee:db:a8:f3:69:fd:6a:7a:6b:4f:52:ae:5c:ba:46:
                    dc:72:35:58:17:48:59:60:76:72:db:5f:ba:50:d7:
                    05:6b:45:b5:84:27:05:b0:86:7a:41:ff:04:32:14:
                    1e:73:1a:78:b4:36:95:e4:dd:04:73:47:ae:19:e9:
                    ed:0c:f7:52:a7:8a:1e:43:96:86:a4:59:d0:51:9b:
                    a9:50:19:38:e0:ff:cd:f8:ed:6c:76:ef:6f:fc:33:
                    33:16:15:d5:27:31:15:6f:c0:b7:9e:2f:22:fa:77:
                    d7:d6:06:a8:51:87:b9:7f:c3:35:0e:33:f5:04:a8:
                    d2:f5:5a:29:c4:1f:e9:db:d0:7e:e7:d0:a2:fc:8e:
                    c7:8b:5a:ca:b5:7d:c1:29:e9:6d:c1:20:01:6f:68:
                    d9:06:27:87:7b:fc:02:e7:4a:d9:32:5d:6b:18:0b:
                    c6:57:b7:06:c8:b9:08:b6:bc:c4:52:76:c3:b8:58:
                    49:9f:46:ca:ef:96:17:88:3c:6a:cf:a9:a9:51:2e:
                    ff:a9:20:52:d0:6b:0e:1c:c9:20:46:3c:28:d5:1d:
                    1d:c0:46:15:18:a6:6a:4d:ec:02:44:7e:78:f7:47:
                    ff:49:49:77:1d:15:c6:6d:07:a2:74:c6:fc:70:2a:
                    d6:e9
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         58:fb:28:e1:99:d0:b5:7b:5d:3d:16:e9:ab:f2:b2:9f:e9:28:
         0f:a0:65:ab:ea:00:69:4b:44:1c:2f:1e:aa:38:60:2a:19:16:
         12:19:5c:67:83:5f:fe:21:d9:eb:dd:cb:ec:be:af:d5:5a:31:
         05:99:73:9a:1f:8e:39:0f:1a:7e:68:7f:d0:ad:6f:76:8f:d2:
         83:e0:bf:27:a2:5c:c2:ca:09:33:e2:88:56:ac:4e:5b:51:58:
         62:d2:57:71:49:02:5b:bd:09:08:a8:fc:70:05:19:f2:8d:b9:
         86:19:4a:d6:53:51:f7:6c:c3:dd:c7:50:24:b0:20:5d:07:3d:
         6a:e0:60:d1:d0:4b:ab:a0:ad:ab:c6:62:5a:a8:79:4d:d9:f0:
         46:a7:27:c5:e1:62:2d:a7:88:2f:30:a4:8b:a6:05:c9:d1:af:
         09:c6:db:08:48:d7:72:4a:89:c9:09:15:de:31:8a:97:17:ea:
         45:0e:f1:c5:a0:25:fe:a1:df:fb:35:6a:b0:56:a3:f6:fe:ae:
         1b:fb:64:9c:95:43:bf:73:26:17:b0:5e:23:2c:9e:45:2f:05:
         3d:0e:6d:32:3b:80:f4:a1:80:6e:fd:15:3d:ad:21:4d:4e:87:
         da:74:c6:48:55:e4:03:5e:3e:9c:c7:ac:c2:40:3e:3f:b0:df:
         9b:59:a1:12


What IMEI(s) does an ISP get in case I use a mobile hotspot to connect my laptop to the web?

The phone company will receive the IMEI of the mobile phone, which is the device connecting to them. You might have one, zero or dozens of laptops behind that phone. Not to mention, laptops don't have IMEI codes (the equivalent would be the MAC of the Wifi card)


How was (is?) the ping of death attack possible with IPv4?

There are many reasons why packet dropping isn't implemented. One example is that there is a technology known as jumbo frames, which allows for up to 9000 bytes of payload. These are primarily supported on LANs where large amounts of data are moved around, and where the repetitive nature of headers is unnecessary.

It's also worth noting that most packets are larger than 56 bytes + header. The standard Ethernet frame size is 1500 bytes. If you are referring solely to ICMP packets, it would be possible to implement such a restriction, but why? There are valid use cases for wanting larger ICMP packets. Having a network stack that properly handles non-standard packets is generally more desirable than having a network stack that arbitrarily limits functionality.


What can I do about TLS 1.0 javascript injection vulnerability on my server?

Theory of the BEAST Attack

SSL uses various combinations of public and symmetric key algorithms. (OpenSSL's list) When the symmetric algorithm is a block algorithm (as opposed to stream), cipher block chaining is used -- the previous block is part of the input to the new block.

The problems we're seeing right now are implementation-based, and they've been talked at least as far back as 2002. This CBC discussion notes that it's generally really hard to construct chosen plaintext in most protocols. HTTP with Javascript is allowing this to happen.

Why are we still suffering from this

We should be getting away from TLS 1.0 and moving on to 1.2. But of course, we still live in a world with SSL 2. More to the point, even where you can switch to newer TLS versions on your server, the ubiquitous NSS library doesn't support it. That means you wouldn't get Firefox or Chrome visitors.

You can use stream ciphers (RC4), and that will prevent the attack. I don't know if the empty opening message from my first link is used at all, or how that would affect various client implementations.

Your personal reaction

Help write TLS 1.2 into the NSS library. Make others know that you consider security a priority. If you have the time, do some research, testing which non-standard SSL configurations will work and what platforms they negatively affect. If you find out that RC4 works with everything, publish that so we know it has been tested.

If you don't have the time or capacity for that... wait it out. That happens too often, but at least a few folks are being squeaky about it.


Conversion of user passwords from SHA-1 & encrypting plaintext data

You will have to wait the users to login to change the passwords. As soon as you validate the password, re-encrypt it with the new algorithm and save it on the database.

But don't use the user password as a key to encrypt the other user data. Doing this you will need to re-encrypt everything again every time the user changes the password. Instead, generate a secure random key, and encrypt this key with the user password. Use this key to encrypt the data. When the user changes the password, you will only have to re-encrypt the key, all other data don't have to change.

If you don't want to leave SHA1 lingering on the server forever, specify a deadline for changing (~3 months), or threshold of converted hashes (75%), and when the mark is reached, expire all SHA1 passwords and instruct those users to reset their passwords when they try to login weeks (or decades) later. This page from OWASP have a nice cheat sheet for that. Basically you identify the user (ask for username AND registered email, for example), send a unique link with an expiring token, and let the user create another password using this unique link.


How are Distributed Denial Of Service (DDOS) attacks resovled

Most of the time, you can only prevent a DOS attack, especially during a Distributed Denial-Of-Service attack, as many Botnet computers or even Bot-Free computers causing the problem lead to amounts of information too hard to trace. Here are some methods of prevention:

Application Front-End Hardware:

Buying intelligent hardware that can analyze data packets and determine which ones are safe and which are not.

Bandwidth Management:

Controlling the amount of network traffic through methods such as throttling and server time-outs.

For more information, visit
this website.


The TPM doesn't stop the boot.  The boot will still continue, but the PCRs will have a different value in them than they used to (since now the BIOS is different than it was before).  As a result, the system will be unable to unseal the sealed data.  Of course, if the bootloader or kernel is unable to unseal the sealed partition, depending on how it is written, it may or may not be able to continue execution without access to the sealed data.

Background: When you seal data, the data gets encrypted under a key associated with a particular state of the TPM.  Subsequently, you can only unseal the data if the TPM is in the same state.  When I say "state", I mean the state of the PCRs.

Example: Suppose you encrypt your drive using BitLocker.  BitLocker seals the data on your hard drive, associated with a particular state of the TPM (i.e., associated with a particular BIOS, bootloader, and kernel).  Now suppose you later change your BIOS.  Then the state of the TPM after boot will be different.  BitLocker will no longer be able to unseal the data, and you won't be able to access the data on your hard drive any longer.  You'll need to use BitLocker's recovery key to access your data.  If you've forgotten your recovery key... well, sucks to be you.

Further information:

The Trusted Platform Module (TPM) and Sealed Storage.  Bryan Parno, 2007.
Understanding and Configuring BitLocker with TPM, Microsoft Certified Professional Magazine, 2008.  (See especially the section on "BitLocker Recovery Password".)
Anti Evil Maid, Joanna Rutkowska, 2011.  (See especially the first few paragraphs, where she explains that the TPM cannot prevent modifications to the BIOS; it can merely retrospectively detect that there was a modification.  At that point, it will refuse to allow the modified software to access sealed data that was sealed by the previous software.)


how to load files in TLS PASS Through in Burp Suite?

It looks like Burp does not support wildcard URLs in its Load functionality.
If I load this file:
burp_urls.txt
-------------
https://*.google.com
https://portswigger-labs.net
https://example.com

Then I get this:

This is consistent with this Portswigger Support question from January 2021:

This sounds like it could be a feature request for the 'Load' option to respect any regex set within the file being uploaded. If possible, can you send the file or an example to us on support@portswigger.net?

So it sounds like if you want this enhancement, then you should email them and request it :)


DNSSEC - does the domain owner owns a key?

At each level, in each zone, records are signed by one (or multiple) key, that is itself (the public part) in the zone as a DNSKEY record.

Also in parent zone a DS record (signed in the zone like any other records in that zone) "points" to the DNSKEY below by the virtue of being an hash of it and the domain name.

This is repeated at each level.
So if you start from root with a fully trusted key (an anchor, that must exist in each recursive nameserver), you find a signed DS record for some key inside the .com zone where you find its DNSKEY record and all other records there are signed by this key, including the DS record of a key for example.com in which zone you will find a DNSKEY record which key signs all other records, hence generating RRSIG records.

(This is of course simplified as often you have separate Zone Signing Keys and Key Signing Keys but this does not change the general idea above).

The keys are typically auto-generated by the nameserver or some external tools at some frequency (typically counted in months or few years). They must absolutely not be handled/generated by the parent zone, each zone is responsible of its keys, how much it has of them, how often it changes them, where are they stored (like on an HSM offline for the KSKs or simply on the filesystem). Each zone only gives a DS record (one per key, specifically one per KSK, including those that do not correspond to published DNSKEY records yet, as a backup), to its parent zone, in order to build the chain of trust.

So it can be the owner of the domain or the DNSSEC signing (and hence key generating service) can be outsourced: some providers will give you a nameserver acting as a bump into the wire, it will serve a signed zone from your content by being a slave of your own nameservers serving an unsigned zone and managing the keys and signatures itself.

The signatures in example.com are owned in a way (depends what you mean by owned) by the authoritative nameservers on this zone. They are either pre-calculated or calculated when the requests arrive (both models exist). Signatures themselves have a starting date and an end date.

Use an online tool like https://dnsviz.net/ to graphically display the chain of trust for any domain. Pass your mouse on various parts of the picture, you have overlays with a lot of useful information.

You can also use dig +trace +dnssec locally. Or better now delv +vtrace or drill -S.


What is the difference between SSL and X.509 Certificates?

SSL is by far the largest use of X.509 certificates, many people use the terms interchangeably. They're not the same however; a "SSL Certificate" is a X.509 Certificate with Extended Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1).

Other "common" types of X.509 certs are Client Authentication (1.3.6.1.5.5.7.3.2), Code Signing (1.3.6.1.5.5.7.3.3), and a handful of others are used for various encryption and authentication schemes.


Create PKCS7 signature, signed by X.509 CA, which embeds an XML file

To be clear, the data to be signed is exactly the contents of a file, XML or otherwise?

You can't sign with only a certificate. You must sign with a privatekey and then provide the matching certificate to allow the recipient(s) to verify the message when they receive it. When using a certificate issued by a well-known CA (e.g. Verisign) you usually must provide a certificate chain not just the single certificate. Some UIs (especially Windows and at least some other browsers) confusingly use the term "certificate" to mean either just a single cert by itself, or a combination of a privatekey plus one cert or a chain of certs.

OpenSSL actually supports CMS (Cryptographic Message Syntax) which is the updated IETF version of PKCS#7, like TLS is the updated IETF version of SSL. If the very small technical differences between the older version PKCS#7 and the current version CMS matter to you or your recipient(s), you will probably need to write a custom program, which can use the OpenSSL library. OpenSSL also supports S/MIME which is basically just CMS adapted to MIME format (used in Internet-email and HTTP).
To confuse things a bit, current OpenSSL commandline has two subcommands:

openssl smime ... an older utility that actually supports both S/MIME and CMS
openssl cms ... a newer utility that also actually supports both CMS and S/MIME

See https://www.openssl.org/docs/apps/smime.html and https://www.openssl.org/docs/apps/cms.html .

The simplest case of signing with embedded (not "detached") data is if you have the X.509 cert and privatekey (both) in PEM format in a file:

openssl cms -in datafile -sign -signer keyandcertfile -nodetach -outform pem|der

Select -outform pem or der depending on which output format you want, but don't omit it; the default format is S/MIME which is not what you asked for. Output is normally on stdout, which you can redirect or pipe to something else as appropriate; add -out outputfile to write directly to a file.

Variations: If you have the key and cert in different files, but both PEM, you can either just concatenate them into one file, or use -signer certfile -inkey keyfile.
If you need to supply a chain cert (or several) and you have it (or them) in PEM format in a file or files, add -certfile chaincertfile once or as many times as needed.
If the "certificate" (and privatekey!) you have is in any other form(s), OpenSSL can convert many other forms (though not all) to the PEM files it prefers; provide more exact details. (Edit your question by clicking on the word "edit" at its bottom; for clarity state which data is added or changed.)
If your data is not exactly one file, but can be selected or otherwise produced by some other program, omit -in inputfile and instead pipe the input of openssl from that other program.

All this assumes OpenSSL is available on the system you use, or equivalently you use a system where OpenSSL is available. If you need to obtain OpenSSL, specify your OS.


How do apps tell if there is a problem with ssl?

sslstrip works by changing all https links to http. It is restricted to HTTP but tools for other protocols might exist or at least are easily doable. These kind of tools don't break the TLS connection but instead enforce a downgrade to an insecure unencrypted connection.

How good these kind of tools can work depends a lot on the application and on the protocols used. With IMAP, POP3, SMTP, FTP and probably others there are two ways to use TLS:

Implicit TLS: In this mode the client connects via TCP and then immediately upgrades the connection to TLS. This is done on different ports (i.e. 993 instead of 143 for IMAP) and on these ports only TLS is expected. Thus there is no way for a man in the middle to strip the usage of TLS, all it can do is to deny usage of these ports which might cause some applications to downgrade to explicit TLS.
Explicit TLS: In this mode the client connects via TCP and after some plain text communication it upgrades the existing connection to TLS by issuing a STARTTLS or similar command (STLS with POP3, AUTH TLS with FTP). If there is a man in the middle (s)he might modify the communication so that the client assumes, that TLS is not possible. The behavior then depends on the client and sometimes on its configuration: some clients will silently use the plain text connection while others will throw an error because they expected to use an encrypted connection.

And even if this is outside of your original question: if a downgrade to plain unencrypted communication is not possible the attacker might try to use tools like sslsplit to do a man-in-the-middle attack against TLS itself. There are still lots of applications vulnerable against these kind of attack (see VU#582497) because they fail to validate TLS certificates at all or omit critical parts of the validation like checking the host name. Thus in lots of cases a TLS man-in-the-middle attack is possible without the user detecting it.


Is this redirect on my website dangerous?

While it is impossible to tell as you have not supplied any source code. I would say, maybe, if you are just checking the website as a sub-string to see if it is valid, have you considered the following?

https://mywebsite.com/?redirectTo=maliciouswebsite.com#google.com
https://mywebsite.com/?redirectTo=evilgoogle.com

There are many ways to get around the restriction of just validating the end of a string. It would be much better if you whitelist the exact domains that are accessible rather than relying on regex.


Why not set Root CA CRL for Sub-CA to be really long?

I completely agree with you -- you seem to understand the complexities of the issue.

Let's look at the extremes:

CRL Lifetime = subCA Lifetime. ==> the CRL is completely useless; you have no ability to revoke the subCA because so long as the previous CRL is within its validity period, clients have no reason to fetch a new one, unfortunately that's how the protocols work.
CRL Lifetime = 1 hour. We have to change how we think about "offline" root CAs.

I agree that 3 months or 1 year seems like a worst-of-all-worlds compromise.

The high-value production CAs I've worked with take the latter approach and keep the root CAs in a "root firewall zone" that allows CRL data out, to be picked up and published by a machine in the DMZ, but no other connections. You still need physical access to the root CA box for anything other than fetching CRLs. The auditors we work with are satisfied to call that "air gapped".

I even heard of one clever solution sending CRL data out over the Line-Out audio jack!


The SIM card, initially, is the root for the legal value. The operator wants to bill the user, and does not want users refusing to pay and claiming that they did not made these three-hours calls to Tanzania. Within the legal context of European countries, where GSM was designed, the SIM card was convenient: it could serve as a basis for legal proofs, under the idea that the SIM card cannot be cloned, and thus if the secret key contained in the SIM card was used then the actual card was used, and the owner could then be formally held responsible for the calls, and pay for it (and three hours to Tanzania imply a non-negligible amount of money).

It is plausible that the SIM card concept was pushed by some French lobbying, the "smart card" being a French speciality (and, at that time, was still patented by some French companies).

Another facet of the issue is that in Europe, you can unlock your phone. Operators are legally mandated to send phone owners an "unlock" code, no more than six months after buying the phone, so that users may then reuse the same hardware phone with another operator. There again, the SIM card is convenient. Compare with SIM-less phones in North America: there is no SIM, but the phone is hardwired (through its firmware) to a specific operator, and you cannot easily (or at all) repurpose the phone to another operator.

The SIM card thus incarnates the separation between the phone hardware and the contract with the operator.

So the "why ?" is, as usual, mostly a matter of History; GSM phones need a SIM card because GSM phones have always needed a SIM card. Yet there are at least semi-rational reasons why GSM phones have SIM cards, and SIM-less phones are not necessarily "better" than phones with SIM.


Conventional Wisdom re: Brute-Force Attack or Enumeration

There are a few ways to look at this. One should start with http://thedailywtf.com/Articles/The-Phantom-Password.aspx before trying to really think about it, though.

There are varying degrees in which passwords are disclosed. My username at Slashdot is known by everybody who reads a post of mine. My username at work can be viewed by everybody in the office, and equally discerned by anybody who knows my email address. Nobody should know my bank account number (which is the username for my online banking).

In each of those situations, the benefit of specifically saying that the username is invalid or that the password is invalid is limited. Now, in that scenario: If you're on Slashdot, you know the account is there forever so you can figure it out regardless. If you're attacking my work, that can give away whether I'm still employed. Against my bank or credit card accounts, that's the only way to enumerate accounts. It provide a clear goal.

I'm of the opinion that since acknowledging one or the other has limited value for public systems and can leak information about private ones that password authentication should always be of the form "do the username and password match?" That is a T/F question with no steps in between.

New Age Wisdom re: Phishing

A user gets to a website, which may be the wrong website. They enter their login credentials without paying attention to the URL (or perhaps they really get spoofed), and their account is compromised. Banks have addressed this by making authentication a multi-step process. To this idea, the original questioner mentions displaying a series of photos if the username is correct. I counter: ALWAYS make the authentication process go through all the steps. jonjacob(jinkleheimerschmidt) may not be a valid login, but you should still display a series of photos and ask for a password. That allows you to stifle the risk of leaking information and still attempt to prevent phishing from compromising a user account.

Risk v. Reward

The conventional wisdom about usernames and passwords above is simple and agreeable to most, I believe. Phishing is a new variable, and dealing with that is going to change the situation for some systems. There are answers to your question which may not be discussed here, or even thought of yet. I still believe, however, that you should be able to prevent somebody from enumerating accounts with any situation.


Can I read/write canary values from %gs register?

Threads share the same address space and code. However, for a variable in thread-local storage, each thread must have its own value; so the variable cannot be simply stored at a fixed address. There must be some indirection.

On 32-bit x86 CPU, with Linux, thread-local variables are accessed through the %gs segment register, which was hitherto unused by application code. Segments are a remnant of older times; Linux has always defined all segments to start at address 0 and extend over four gigabytes, allowing code to forget them completely. However, they are still there, and one of them (%gs) was revived to support thread-local storage. Indeed, all threads share the same memory, but each thread has its own set of register values.

The canary is a slot on the stack. Its purpose is to be overwritten when an overflow occurs, and the overflow is likely to impact the return address: the value which is written in the slot must be read back unchanged at the end of the function. That specific value is randomly chosen at the start of each thread, and each thread has its own; this means thread-local storage, so the canary value for a thread can be read by that thread at some fixed place relatively to %gs, as known by that thread.


Symmetry meaning in cryptographic algorithms

It only refers to the symmetry of the keys.

There are a number of block ciphers and modes (symmetric crypto) that have slightly different encrypt and decrypt routines. Yet they are still symmetric crypto. AES for example uses a number of building blocks for which there are inverse operations used to decrypt.


I investigated a lot on this in the last few days:
By default, Linux drops packets with MAC address different from the NIC MAC address on which it gets the packet. Promiscuous mode should modify this behaviour.
If the ARP-spoofing attack has had success, the Man in the middle will receive packets from R and S (see my question for S and R definition), which will have P MAC address (this is the point of ARP spoofing) but different IP. You can read this packets using different tools such as Wireshark. I experimented with libcap (I used that library in a C program), that I think is used by Ettercap, and by that, you can take those packets and also modify and re-forward.
Please note that Ettercap does not enable IP forwarding by default doing:

echo 1 > /proc/sys/net/ipv4/ip_forward

Otherwise, the Kernel itself will forward the packets, but Ettercap also offers packets modifications and packets drop, that is possible just if the Kernel does not take care of those packets.


The Diffie Hellman parameters are not secret. In fact they are shared entirely during every key exchange. Reusing them should not be a major issue in general, if they are of good quality and length.

At one time it was reasonably common to use 512 bit parameters. An attack called logjam was discovered whereby data to decode the key exchange could be pre-computed allowing reasonable attacks. This is considered to be impractical for even 1024 bit parameters, so using 2048 or 4096 bit parameters eliminates the possibility of a pre-computation attack on your specific values entirely.


What happens when captcha keys get compromised?

I assume you are talking about recaptcha keys. The answer is not much happens if your recaptcha secret key is compromised. As far as I know, the key is only used to verify the server's identity to google's api when verifying the user's response. Since the response can only be verified once, an attacker cannot use it to bruteforce the solution to the captcha and therefore cannot bypass the captcha simply by learning the secret key. The attacker can use recaptcha with your key, but since recaptcha is already free, there is no point in doing so.
As @ThoriumBR mentioned, the attacker can abuse the service in which case google will detect anomalous activity and block your account. This could result in DoS for your website while you try to clear up things with Google. Your service being suspended would be the most obvious indicator of your key having been compromised (atleast if google informs you why it was suspended).


How can data execution prevention be implemented on websites and web applications to prevent privilege escalation?

Techniques like DEP, NX, PaX, W^X etc only help against a specific type of attacks which uses buffer overflows or similar. Usually web applications are written in higher level languages which are not prone to this type of attack. The typical server side attacks against web applications are SQL injection, local and remote file inclusion, broken authentication etc and in none of these cases DEP will help.

But, these attacks where DEP does not help usually result only in non-privileged access to the server system. In order to get system privileges the attacker then uses local exploits which often work because of buffer overflows or similar. And in this case DEP or similar techniques can make it harder for the attacker to get system privileges. Which means that it is not DEP for the web applications itself which helps but DEP for the locally installed programs and for the kernel.

Of course there are also cases where the web application itself might profit from DEP. This is the case for applications written in lower level languages like C and C++. Such applications are often found in embedded devices (router etc).


Keep things simple, if you want anonymity, don't use email for logins.

Make your user generate an asymmetric key pair to authenticate to your system, call this the login key.

When the user want to post a message to your system, the user generates a new asymmetric key pair, call this the data key. The user would then sign their message with the data key and encrypt the private data key with their public login key addressed to themselves. The user would submit the encrypted private data key, the public data key, and the signed message.

To edit the posted message, your user downloads the encrypted data key, decrypt it with their private key. And then they sign the message with the private data key. Your system knows that the new message are generated by the same user as the original, because both messages are signed by the same public data key.

Be careful:

many implementations of asymmetric cryptography attaches the encrypting key's ID to an encrypted message, to make it easy for the recipient of a message to identify which key to use to decrypt the message. You want to make sure you encrypt the private data key without adding these metadata.
an attacker that manages to observe who downloaded which encrypted private key would be able to observe which user downloaded which key and make reasonable guess as to who is doing what. You can prevent this by forcing all users to download all encrypted private keys (or a reasonable chunk of it).

  Basically I store <SHA512(email), salt, iterations>

If you're storing the SHA512 of the users' email, wouldn't identifying the users be as easy as creating a SHA512 rainbow table?


Security Audit - How to make sure a specific android app does not send my data to its data center

Is there a way for us to prove that this specific software does not randomly access device storage (while the app is running in the background / not active) and send the data to their data center?

First of all, the auditor should provide evidence that data is sent to a data center. Failing a security audit based on the assumptions that an application might send data to a data center is not valid. The audit should be all about facts.

Network Traffic

In order to monitor possible HTTP traffic of this mobile application, one could use an intercepting proxy for example. The certificate of this proxy is loaded into the phone and should be trusted in order to capture the TLS data streams.

Configure the phone to use a proxy server and point it to the IP address of the machine that is running the proxy.

Side Note: Make sure the intercepting proxy server is listening on an external network interface in order to accept connections from the phone. Any web based traffic should be captured now and displayed in the intercepting proxy.

When HTTP is not expected to be used as a communication protocol, it will be a bit more difficult to analyze the communication stream. In that case I'd suggest use a Pinapple device. Connect the phone to the device over WiFi and use TCP dump to capture its traffic.

TCP dump allows you to store the network capture in PCAP format. This PCAP can be loaded in a tool such as Wireshark in order to analyze all traffic.

Data Storage

First of all, requesting storage permissions should not fail an audit. It can be perfectly legitimate for the application to (temporary) store data on the storage device.

Again, it should be proven that the application could maliciously do things on the storage device.

Analyzing the application

In my opinion the best way to analyze the application is by reviewing the source code. If the source code is available, this is the best and fastest way in order to determine if data is sent to a remote server and if it will randomly read data from a storage device.

In case the application source code is not available, it could be decompiled and analyzed (I'll leave the law out of this for now and focus mainly on the technical details)

Conclusion
I cannot stress this enough: It is the auditor's responsibility to prove that the application performs malicious actions. Assuming an application might be malicious is not good enough.

The auditor should be provided with a security assessment report that is performed on the application. Based on that report, the auditor can state whether the application is malicious or not.

It's all about the evidence!


Protecting against specialized Keepass attacks

In such a situation, is there a way to still use KeePass, but protect against specialized attacks?

Absolutely; the simplest and most basic is called "air gap" protection.

Take a computer with no network connection, no speaker, and no microphone, such as a Raspberry Pi 2.
Use wired keyboards, mice, monitors, etc.  No wireless anything!
Set it up with the minimum required software - if you insist or for a basic proof of concept, you can start with NOOBS Raspbian.

Patch it, ideally offline (see below for one-way transfers), but you could do it online before you actually start using KeePass at all

Fill the ethernet jack with epoxy; it is NEVER to be used.
Install KeepassX
NEVER AGAIN move any data off this machine in any electronic way.  Updates can go in, but nothing comes out electronically.  Read the screen and hand-type.

burn CD-ROMs with whatever updates you need to move to the KeePass only machine and then use a USB CD-ROM to read them, then shred the CD (just in case something got written to it).
or use something like an Apricorn flash drive; wipe it, set a password, put the data on it, enter the password and use it on the KeePass machine, then immediately wipe it again BEFORE it goes in any other machine.

For the truly paranoid, use a dedicated monitor, mouse, and keyboard that never get used for anything else; the older and less advanced the better.
Don't use it where any electronic cameras - like your laptop/webcam/fancy video conferencing monitor - can see screen emissions.

This way, even assuming that some specialized software gets onto the machine, someone has to be in reasonable physical proximity to be able to extract data; hear the sounds the chips and/or power supply make, watch thermal patterns, see the emissions from the machine, monitor, keyboard, etc., but the machine itself has no networking or radios at all - no bluetooth, no wifi, no cell modem, no ethernet cable, etc.

CRITICAL - back up that KeePass file regularly to something like an Apricorn mentioned earlier, or paper (dedicated printer, no networking, no wireless capability), etc.

CRITICAL if using a Pi - run that Raspberry Pi on a UPS of some sort - Raspbian reacts very badly to sudden power loss while turned on some of the time.


Bruteforce with hashcat, how to set the mask properly?

Complexity rules like these cannot be natively captured by a single mask. Instead, a list of many masks that fit the criteria must be generated using other tools, such as the policygen tool from the PACK toolkit.

$ policygen --minlength=8 --maxlength=20 \
  --mindigit=1 --minlower=1 --minupper=1 --maxspecial=0 -o test1.masks

$ policygen --minlength=8 --maxlength=20 \
  --mindigit=1 --minlower=1 --minupper=1 --maxspecial=1 -o test2.masks

(Note that these examples don't include your "one or more identical consecutive characters" constraint, because A) this dramatically increases the complexity of the masks, almost to the point of impossibility, and B) it does very little to speed up the cracking process, so it's not worth including.)

You then pass hashcat that file containing the masks:

hashcat -m 5500 -a 3 test.txt test1.masks
hashcat -m 5500 -a 3 test.txt test2.masks

Be aware, however, that bruteforcing longer lengths (like 12, let alone 20) will take longer than you have. If you haven't already, I recommend that you try other methods (dictionaries, hybrid, etc.) before resorting to brute force.


Device versus file based encryption in TrueCrypt for a flash drive?

Truecrypt has an article discussing wear-leveling.  It would appear that Truecrypt still provides a secure solution as long as you can be sure that your keys have not been compromised.  It makes no statement regarding the differences between file-based containers vs. device-based encryption, and so it is likely there are no security tradeoffs to be had aside from those you've already stated.

Therefore, multiple "versions" of a single sector may be available to an attacker. This may have various security implications. For instance, when you change a volume password/keyfile(s), the volume header is, under normal conditions, overwritten with a re-encrypted version of the header. However, when the volume resides on a device that utilizes a wear-leveling mechanism, TrueCrypt cannot ensure that the older header is really overwritten. If an adversary found the old volume header (which was to be overwritten) on the device, he could use it to mount the volume using an old compromised password (and/or using compromised keyfiles that were necessary to mount the volume before the volume header was re-encrypted). Due to security reasons, we recommend that TrueCrypt volumes are not created/stored on devices (or in file systems) that utilize a wear-leveling mechanism (and that TrueCrypt is not used to encrypt any portions of such devices or filesystems).


What does Spectre mean for public cloud computing?

Spectre is far harder to use than Meltdown.  In a cloud hosting situation, an attacker needs to know:

What software the target is using
Where in memory that software is
Where in memory the target data is
The behavior of the host CPU's branch predictor
The behavior of the host CPU's speculative execution system
and possibly some other things I'm forgetting

It's also much slower than Meltdown.  (Meltdown can read protected memory at a rate of around 500 kbyte/sec under good conditions.  The Spectre paper didn't give a speed, but the need to train the branch predictor for essentially each byte read means I'd expect a rate of single-digit bytes per second.)

Because of the difficulty in using it, Spectre can't usually be mass-deployed.  I expect three-letter agencies will be making heavy use of it, but it's the sort of thing you'd use in a highly-targeted attack, where Meltdown is better suited for untargeted sweeps for interesting data.

In the short term, probably the best thing that hosting providers can do is make it easy for users to run their own software.  A Spectre attack tuned for Apache 2.2.34 for Debian Wheezy on x86-64 is totally useless against Nginx, or against Apache 2.2.33, or against Apache 2.2.34 built with different compiler flags, or...

A fully virtualized system that emulates all aspects of the CPU should be immune to Spectre, but full virtualization is slow.  Hardware-assisted virtualization may be vulnerable if branch-predictor training is shared between the VM and the host, while paravirtualization, sandboxing, and containers are completely vulnerable.


Blocking the SYN,ACK response is not the right way to go about SYN flooding. Every TCP 3-way-handshake starts with a SYN. If you block the SYN,ACK response, no client will be able to successfully connect to your server anymore.

I recommend reading up on SYN flooding and prevention techniques in this Hakin9 article. The key mechanism, if you want to solve it with an iptables rule set, is limiting the rate of SYN requests from a single IP. The following is a suitable configuration, although you could of course have false positives, if a get a lot of legitimate requests from a single IP address (e.g. if there is a large network behind a NAT).

# iptables -A INPUT -p tcp -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
# iptables -A INPUT -p tcp -m state --state NEW -m recent --set -j ACCEPT


Does filtering HTML syntax prevent a web shell from being dropped through a textbox?

It is very unlikely that this would be a viable route to dropping a web shell. The input is probably stored in a database, not in a file, so the interpreter (ASP, PHP, etc) will not process it as source code. A much more likely attack vector is Cross Site Scripting, if the filter is not strict enough.

EDIT to answer 2 points added later:

There is no way to know if the filter can be bypassed without analyzing the source or attempting to bypass it.
Understand how the PHP interpreter is invoked by the web server. In most cases, the web server calls the appropriate interpreter based on a file's extension (e.g. .php calls the PHP interpreter). The web server does not retrieve content directly from the database, so it cannot invoke the interpreter on database content. A vulnerability would exist if a PHP page retrieved user-defined strings from the database and eval'd them. I hope you can understand how unlikely such a situation would be.

Shortest form of this answer: Probably not, but try it if you don't believe me.


Is it OK to set SSL fullchain to service

Pointless, but not dangerous

In order to understand the answer to the problem, we need to understand how certificates work. When a program encounters a certificate and it wants to verify the authenticity of it, it looks at the certificate itself, as well as the Issuer of that certificate (aka. the one who signed it).

That process is repeated until either:

A trust anchor is found (Success)
A validation error occurs (Failure)
A certificate is missing (Failure)
The top is reached an no trust anchor is found (Failure)

This means, if I have a certificate "Leaf", signed by "Branch", signed by "Root", then I need to verify three certificates. In order for this process to succeed, a trust anchor needs to be found. 99% of the time this will be "Root". Since I already need to be aware of "Root", there is no need for the certificate chain to include "Root".

Some examples to illustrate

Leaf + Branch are sent

This is the typical scenario. A client would first verify "Leaf", then verify "Branch" and finally search for "Root" in its own trust store. If "Root" is found, then "Leaf" is a trusted certificate (assuming all other data is valid). If "Root" is not found in the trust store, then the certificate is not trusted.

Leaf + Branch + Root are sent

This is what you referred to as the "fullchain" scenario. Verification works the exact same way. If "Root" is found in the trust store, then "Leaf" will be trusted. If it is not found, then it will not be trusted.

Leaf + Root are sent

This scenario is most likely a configuration error. When "Leaf" is being verified, the program would then attempt to verify "Branch". Since this certificate is missing, the verification fails, even though "Leaf" is valid. The fact that "Root" exists doesn't matter to the verification process, as the link between "Leaf" and "Root" can't be established.

Leaf is sent

This scenario is also a configuration error, but a far more common one than above. The outcome is the same nonetheless, since "Leaf" depends on "Branch", which is missing.

Summary

You can send the full certificate chain or omit the root certificate. It has no security implications, although sending the root certificate is pointless and just wastes bandwidth.


How to securely load data to a database in vendor server such that vendor does not see raw data at all?

There is no point in sending up the files encrypted to then have the vendor decrypt and process them. If you don't want the vendor to access them then the only options are to not send them up in the first place or send them up encrypted without giving the vendors the keys.

If the vendor can decrypt the files then, by definition, they have full access to the files, and there is no way you can also not give them the files. Your goals are mutually contradictory.  Either send the vendor the files and trust them to abide by the terms of your business agreement, or send the files encrypted and don't give them the keys. There is literally no middle ground here.


What could cause a sudden influx of unfiltered spam email?

The most reasonable explanation is that your email address recently ended up in a email list used by spammers.

How could this happen? There are at least three possibilities:

you recently subscribed to a website, who secretly "shared" email addresses with shady organizations;
you subscribed (perhaps a long time ago) to a website which was recently breached, and the resulting email/password dump circulated in underground communities;
someone directly gave your email address to spammers, as a prank. Unfortunately, there are individuals and websites devoted to this ridiculous activity.


Should TVRA be done physically by going to the datacenter?

As ever so often: it depends.

What does it depend on? Your level of trust and your level of risk appetite.
Do you trust the operator of the DC to answer a questionnaire honestly and what risks are you willing to take in that regard?
You can start by sending out the questionnaire, as you had already planned. Some business partners see questions like this as indecent, so handle this with care.

The operator's answers might lead to a breach of contract, so the questions have to be formulated well. Get in touch with your legal department and/or take look at the contract that you have with the operator.

There are several reactions that might lead you to build more trust or lose trust in your contractor. Make expectations clear internally for different scenarios and set goals, like you would in every other project. If all answers sound too good to be true, book a flight. If everything sounds terrible, don't book one - and think about terminating the contract.


Is it safe to use an Android Server Monitoring App, to login to a server with SSH?

To answer your questions:

No (cf. d1str0s comment)
Probably not. This could still be used to leverage exploits to gain root privileges locally - or otherwise make use of your machine without your knowing with regular user privileges (like sending spam).
Supposed it uses SSH to connect, apart from it sending away your credentials, probably not.
Two options here from the top of my head:

Write an app yourself, so you can trust it (or search for open source that a community approves)
Use an administrative web backend to your server to which you can login using your browser


1- What are the possible flaws on this?

That depends on the exact configuration and security measures of the network because to migrate this you will need to mess around with some protocols. I can imagine some ways to migrate this but every solution relies on some protocol weaknesses and the exploitation of these might be detected by an IDS.

On the other hand it might happen that you can't simply "take over" the controll if ssl is used to verify the identity of both sides.

  2- Is there any "deauth-like" attacks for wired connections?

In the way you described it: Yes that can be done by exploiting any protocol weakness that allows a MiTM attack. The only difference is that in this case you don't forward the received information but act as the server that was ment to be reached. In a local network this can be done by one of these attacks for example:

Port-Stealing
APR-Spoofing
DHCP-Rogue-Server (Requires you to be "nearer" at the victim then the real DHCP-Server. Ideally you are connected to the same switch but the DHCP-Server is not.)


Do the servers see my IP when using a VPN?

My comments may have been terse and vague because the reasoning behind this subject depends on an understanding of networking concepts as well as how VPNs behave. So here's the long version.

  The innermost IP header is my publicly routable IP address that has been encapsulated. The outermost IP header is what is used for routing purposes.

False (you can confirm this with Wireshark). This simply won't work, and we'll see why later.

When you start up a VPN client or server, a special interface is added to your system. On a *nix system, this will typically be called tun0 (assuming a TUN VPN, and where additional TUN devices follow the scheme tunN). This special interface is used for communicating over the VPN, and by default (for OpenVPN) is assigned addresses in the 10.8.0.0/8 range. For public, "privacy-providing" VPNs, they will also typically set your computer's default route to use the OpenVPN server on this interface, which is also in 10.8.0.0/8. If this is the case, all of your outbound traffic will have a source address in 10.8.0.0/8 and will be sent to the tun0 interface. The VPN client will then send the encapsulated traffic over your regular network interface to the VPN server.

This is what both IP headers would look like for a theoretical packet:

Outer Header: SRC=<YOUR_PUBLIC_IP> DST=<VPN_SERVER_IP>
Inner Header: SRC=<YOUR_VPN_CLIENT_IP> DST=<WHATEVER_YOU_ARE_ACCESSING>

The VPN server acts as a router. Once it receives your packet, it will route it depending on its destination address and the server's routing table. If this VPN serves a corporate network and static routes already exist on other routers back to the VPN range, the work is done here.

However, in the case of a public "privacy-providing" VPN, an RFC 1918 source address such as 10.8.0.0/8 cannot be routed back to across the internet, and thus can not be preserved all the way to the destination server. Instead, the VPN server or another router in their network must perform source NAT to rewrite the source address with the VPN provider's public IP address, so that the return traffic will come back to them. A connection tracking table records the original source address and port so that it will make it back to your client machine through the VPN.

While that was long and convoluted, it means that the answer to the following is "no".

  This means that the actual identity of the source is never concealed
  from the end device. Is that right?

When in doubt with these sorts of things, I highly suggest opening up a tool (e.g. Wireshark) to see how things are actually working.


Which are open problems on policy-based access control system?

The magic word is RSOP = Resultant Set Of Policy.

Any useful tool tool should show

what the result of all policies are together (as if it was a single policy),
which policies took precedence and why, and
which did not take effect/were overridden by other policies and why,
Any policies which were corrupt or otherwise meaningless.


There is nothing you can "install" to deanonymize an attacker. Once you get the data from Kippo about the IP and connection type, you have as much as you can get unless the attacker reveals more about themselves from their actions. There are tools that you can use to enhance the data a little, but that does not break anonymity.

Most of the investigations that uncover the cracker's identity that I have successfully performed have been the result of the files they try to install or the download locations they use or the passwords they try to use. So, it's all down to a manual investigation. It's not the data that Kippo captures that does it, it's the data that the Kippo data points to that does it. And it's difficult to predict what that might end up being.

... Unless you break the law and hack the hacker back. I know one person who ran a Kippo honeypot and configured a script to use the same password the attacker set for a new account to try to log in to the attacker's machine. He had a 10% success rate (attackers re-using passwords). But, this is illegal in most jurisdictions (unauthorised access).


You are trying to attack a service that runs the Asterisk Manager Interface (AMI) protocol. For that reason, Hydra verifies that the server returns an appropriate banner that should look similar to Asterisk Call Manager/1.1. If it can't identify the banner, Hydra will abort the attack.

So the error simply means that Hydra couldn't verify that the target is using the Asterisk protocol and you are possibly attacking the wrong server/port or the target uses a different protocol.

This is the relevant part from the source code (hydra-asterisk.c):

  //banner should look like:
  //Asterisk Call Manager/1.1

  if (buf == NULL || strstr(buf, "Asterisk Call Manager/") == NULL) {
    /* check the first line */
    if (verbose || debug)
      hydra_report(stderr, "[ERROR] Not an Asterisk Call Manager protocol or service shutdown: %s\n", buf);
    hydra_child_exit(2);
  }


ne.jp is not a domain name. It's a second-level TLD, similar to co.uk.

outpost@alpha.ocn.ne.jp is an email address under the domain alpha.ocn.ne.jp, which is a subdomain of ocn.ne.jp -- a large Japanese Internet provider.


Why does Directory traversal attack %C0%AF work?

First, URL encoding also know as percent-encoding is simple scheme where in the URL %xx represents a byte (a number from 0-255) where each x is a hex digit (base 16: 0-9A-F; note 16*16=256 the number of different bytes).

Hence %C0%AF in a URL corresponds to putting the bytes C0 AF into the decoded URL, meaning bytes 192 (1100 0000) and byte 175 (1010 1111), while %C0%2F corresponds to bytes 192 (1100 0000) and bytes 47 (0010 1111)

Now ASCII only defines symbols for bytes 0-127.  The most common extension to ASCII to allow special symbols (e.g., for non-English writers) is unicode.  Unicode translates symbols like / to codepoints represented by numbers; e.g., / is 47-th codepoint (in hex 0x2f), π is the 960th codepoint (0x3c0), and ♥ is 9829-th codepoint (0x2665).  Now for unicode symbol to be put into a stream of bytes it has to be encoded, and the most common encoding nowadays is UTF-8, as UTF-8 continues to encode ASCII characters in a single byte (8 bits) so it doesn't screw up encoding of plain old ASCII documents.  Note ASCII only defined 128 symbols (between 0-127), which all have the first bit as 0.

The way UTF-8 works is normal ASCII characters are still encoded as usual using one byte, which a decoding application recognizes by noticing the first bit is 0.  When you get to the next byte to process, if you see that the first bit begins with a 1 it indicates that the next symbol is represented across multiple byte sequence.  The number of bytes is determined by the form of the first byte (specifically, the number of leading 1 before the first 0 in the first byte).  For example, if the first byte of the multibyte sequence is of the form 110x xxxx that indicates that the next symbol is represented with two bytes.  Similarly 1110 xxxx means it is the start of a three-byte sequence, 1111 0xxx is a four-byte sequence, etc.  Now, if you read the UTF-8 wikipedia page, you'll notice the two byte sequence should be in the form 110i jklm  10no pqrs to represent the unicode codepoint with the binary number ijk lmno pqrs, which in principle could be any binary number from 000 0000 0000 (0) to 111 1111 1111 (2047).  In our first case (C0AF), we have the bits 1100 0000 1010 1111, which represents the codepoint 00000101111 = 47 = /.  Note that 47 could also be represented more simply with just an ASCII character / that is as the bits 0010 1111.  You may wonder why the second byte is defined to start with 10 -- UTF-8 put this in, so you can tell if a character is a continuation of a start of a multibyte UTF-8 character to help catch errors.

So this seems to allow multiple ways to represent every unicode character.  But this isn't allowed in the unicode standard.  Two byte sequences are supposed to have go to values only between 128 and 2047, so C0AF shouldn't represent a / but be an error.   However, unicode libraries are often designed to be fast, where people may not consider the security-implications.  Thus some library may choose not to check that the value of the two-byte unicode character is in the valid range (even though the unicode standard forbids this).  Or the developer decided that if given a C0AF mostly likely some malformed UTF-8 application meant to send 2F, so decides to fall back on the most sensible behavior to be most convenient to the user (as displaying a / seems more sensible than any other choice of character to display).

Similarly, the even more flawed %C0%2F version also works in some bad unicode libraries, because many applications that decode unicode do not check that the first bit of the second byte is actually a 1 as the previous byte already indicated it was a two byte codepoint.  That is the bad decoder accepts 110i jklm  ??no pqrs as a valid two byte codepoint regardless of ?? being 10 as the UTF8 standard mandates.  The first two characters of the second byte are redundant, so a quick and dirty unicode decoding application could decide to not check that these characters match the proper value.

So now that we know why %C0%AF and %C0%2F both ultimately decode to the symbol / with unicode decoders that skip proper checking.

As for why this succeeds in allowing directory traversal, it often happens that the filtering of improper input and decoding the unicode symbol is done at different stages of the application.  The web server may be smart enough not to allow someone to go to navigate through to http://www.example.com/../../../etc/shadow or even http://www.example.com/..%2f..%2f..%2fetc%2fshadow by factoring out improper symbols.  However, if a web server is serving files and decoding the unicode is done after the check that prevents directory traversal or done slightly differently by the operating system, this attack may get past the filter allowing the attack to work.

For a more detailed accessible introduction to unicode, I recommend "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".


Does the VPN provider will have access to my content?

A VPN will provide a secure tunnel between the device running the VPN client (your dd-wrt router) and the VPN server (hosted by your VPN provider). All traffic that gets routed through the tunnel will be reasonably secure against monitoring and tampering, but only while its in the tunnel.

On either end of the tunnel, it is still vulnerable. The VPN provider will be able to monitor all of the traffic as it passes in and out of their end of the tunnel, just as your dd-wrt router will be able to monitor the traffic as it passes in and out of its end.

A VPN is only useful if:

You trust the network and/or device running the VPN client
You trust the VPN server
The adversary you wish to protect yourself from is thought to be somewhere between the two

The same goes for HTTPS and anything else that uses SSL/TLS.


A first generic comment is that when you give a key to a friend, there is no way you can prevent that "friend" from sending the same key to other people, or blabbering about your semi-private information. In that sense, encryption cannot make a useful distinction between "keyF" and "keyA". In a security setting, there are only two categories of information: that which you do not tell to anybody, and that which you tell to at least one person. Since it would be quite pointless to upload the former on any server, we could say that there is, in a social network, only one kind of information, meant to be shared. And you cannot really control how far some data is shared.

This is not new. Propagation of secrets through gossip is a well-known phenomenon and is probably as old as language itself.

However you may try to work in a setup where friends are "trusted", i.e. they will keep secrets (I strongly doubt this scenario is practical if the set of friends includes more than three people, but hey, one can always hope). In that case, you may indeed share data by revealing to these select few the key which encrypted the data. This then calls for a second important comment: you cannot enforce forgetfulness.

This means that if you want to "remove" a friend, then you cannot make him "forget" the key which was previously shared. The only method is to create a new key, share it with your remaining friends, and thereafter encrypt your data with the new key only. This implies that removing people from your set of friends implies distribution overheads proportional to the number of remaining friends. This may cause scalability issues.

It is somewhat unclear what you are trying to protect against. Server operators ? Search engines ? Your friends ? Maybe traffic analysis (i.e. reconstruction of the friendship graph) ? This should be defined with great precision. Appropriateness of any algorithm of protocol can be analysed only if we know what kind of security property we want to achieve.

I still urge you to consider the generic comments above. They can be summed up as: data propagation is hard to control. It makes things simpler to think about social networks as repositories for public data: everything you write on such a network may become public or close enough.


how end certificate refers to intermediate certificate

Chain building is a multi-step process which involves a lot of operations.
Subject and Issuer pair is used only to bind certificates in temporary chains. Certificate chaining engine attempts to build as many chains as it can. After a set of chains is built, all chains are validated according to rules described in RFC 5280 §6.1. During this process a tighter binding is performed using other fields (Subject Key Identifier and Authority Key Identifier) and signature validation. Any invalid chain is eliminated. In the end, certificate chaining engine gets single and best (among others) chain with its status.
I have a blog post which describes how CCE works in general: Certificate Chaining Engine — how it works


I have found ports on my Samsung smart tv running a display service. What can I do with it?

While this isn't strictly a security question, I'm unsure if the Stack Exchanges for Super User or Networking would take this, so I'll just answer it quickly:

Depending on your options, nmap will return different results for ports because different steps for service reconnaissance are taken. Since you seem to use a GUI to nmap and are asking a security beginners question, I'm assuming it's the default options, untweaked. In this case, per /usr/share/nmap/nmap-services this is:

 display 7236/tcp        0.000000        # Wi-Fi Alliance Wi-Fi Display Protocol

If the port does in fact match (unfortunately, you did hide that information from us), this is probably a Miracast instance.

From there you can see the direction the display sharing is supposed to work (emphasis mine):

  Miracast is a standard for wireless connections from devices (such as laptops, tablets, or smartphones) to displays (such as TVs, monitors or projectors), introduced in 2012 by the Wi-Fi Alliance. It can roughly be described as "HDMI over Wi-Fi", replacing the cable from the device to the display.

TLDR:

  Does this mean it can cast its own screen, or that i can cast my screen to it?

The latter.


Block mobile tethering on android phones from Windows (DLP)

Some antivirus software like Sophos can disable network bridging, which will prevent any wireless from been connected while the network cable is plugged in. We use this to stop people tethering while connected. You will need to block USB/Bluetooth at the OS to stop tethering there.

Once a users laptop network leaves the premises you can use group policy (if Windows) to black/white list SSIDs. If you don't do this then nothing to stop a laptop user from going down the street to a coffee shop for the same effect.