You would need to use JTAG, a debugging protocol (specifically IEEE 1149.1)  and its interface on most modern devices. When a JTAG probe is attached, you can halt the machine state and read all the memory and registers. JTAG puts the system into a low-level debug state called probe mode, which the operating system has no control over. JTAG probes, prior to DCI, can be fairly expensive. The only trace left over by JTAG is the fact that the system's RTC will seem to jump forward. After all, the system will be in a stasis which it is unaware of for some time, while the RTC keeps ticking.

It is also possible to use a DMA attack which will typically have very little effect on the target system. However, a DMA attack on a running system is subject to memory smear which may complicate analysis and corrupts the memory temporally, rather than spatially (i.e. address x and address y may have been captured at different times, leading to inconsistencies). Additionally, DMA attacks require that the target system not support DMAR, which filters DMA using its IOMMU.

If you actually want to take the memory and drop it directly into a VM so it runs where it left off, you are out of luck, sorry. There is plenty of state which is not captured in memory (registers, PCI device configuration space / MMIO, etc). It would be an incredible undertaking to take the memory of running hardware and put it into a virtual machine, especially because you would need to write device emulators for all the proprietary devices on the target system. You should be able to comprehensively analyze a memory dump without it needing to be dropped into a virtual machine.

See some other answers I've written on this subject:

A: How can a user defeat anti-live forensics software?
A: Best strategy to recover running Macbook “modern” Pro ram


Rainbow tables, generation and lookup, preferably using GPU

Rainbowcrack is the defacto standard rainbow table generating program,  but its really old.  Someone recentaly wrote patches for John The Ripper to support GPUs. JTR is nice,  especially now that most password hashes have a large salt.

This is a cool project that is using the same software that powers folding@home to generating rainbow tables that can be downloaded for free.  Its best to hit the password with an existing rainbow table,  and then hit it with JTR.

Or if you are breaking WPA/WPA2,  hit it with cowpatty, and if that fails then hit it with pyrit. (WPA-PSK is complete and utter trash)


How to get private keys for traffic decryption?

DH is point to point key exchange.  The best method is to break the encryption and rebuild a different tunnel to the end point of the network. This will cause high load.
Most corporations, as soon the packet enters in their secure network, they are forwarded decrypted to allow analysis without performance impact.

I think most of the devices cannot sniff that type of traffic, só you will need to break the tunnel.
Even if you have the private key, the key pair generated by DH is between the origin and destination, middle systems will not be able to get the key.

What I mean in breaking the tunnel is for your devices to have their own certificates and private keys in the same way as servers and act as endpoint for the communication.

[added]

Generate your tool csr and request certificates for each site you have. If you own the sites it won’t be a problem and you will be able to read trafic. Same way as if your appliance was a web server.
Many tools do not allow it. Others allow it but restrict this to a small number of virtual servers hosted.

Collecting the private keys from the web servers might  not be sufficient. You have to break the tunnel and not eavesdrop at it.

To get the private keys from each site. The site certificate needs to be exportable, you need to know the password if any and export it to a file(private key), then in your ids you should proceed importing it. But that is probably what you already have done due to the fact that your statement says you can read trafic only some specific DH is not possible... :)
The process of exporting the keys changes a bit if you have a windows or a Linux, easy to find in the internet.

Why you can read TLS_ECDHE_RSA_WITH_AES_256_GCM_S HA384  they are not using Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite to exchange keys but ecliptic curve. if you snif the packets and see if the cipher suite specified begins TLS_DHE or SSL_DHE, you will not be able to decrypt the data.


SSH - If Eve has the passphrase and public key, can she derive the private key?

The private key is unrelated to the passphrase. So is the public key. The public key is also generally stored unencrypted, even when the private key is protected by a passphrase. (Exceptions may exist where the public key is stored in an encrypted form, but in the basic case and assuming a sufficiently large key, doing so provides no additional security because the public key is meant to be publicly distributed or at least can be assumed to be available to an adversary.)

Now, don't get me wrong. Protecting your private key with a passphrase is a very good idea, and it is best practice to do so. The private key and the public key have a mathematical relationship to each other. But your private key is still just a number. This number is unrelated to the passphrase you use to encrypt the file that holds this number, which is all the passphrase does.

  If an attacker Eve knows the passphrase in addition to the Public Key; Can they derive the Private key? - I presume yes with enough time.

The public key is mathematically related to the private key, and the simple answer is that yes, with sufficient time, in theory, one can be derived from the other. The public key almost by definition needs to be transmitted in the clear in order to establish an identity before the encrypted communications channel is set up, so Eve (by convention Eve is a passive eavesdropper; Mallory is an active man in the middle) can see it.

Deriving the public key from the private key in RSA is easy. Deriving the private key from the public key is supposed to be computationally infeasible, and with sufficiently large keys effectively impossible. So far as we know, there is no fast way to derive the private RSA key data from a 4096-bit public RSA modulus on a classical computer (which is what we currently have). Even an efficient attack on a 2048-bit public RSA modulus would be quite a feat, though 1024-bit RSA is within the realm of possible in reasonable amounts of time and a 768-bit RSA private key has been factored in public (it took the equivalent of on the order of 2,000 CPU-years on reasonably modern hardware).

So, "with enough time", it is possible. But that is unrelated to the passphrase, or lack of passphrase.

To understand the why of the above, I will use textbook RSA for simplicity. (Real-world RSA is similar to, but not exactly the same as, textbook RSA, as there are many real-world attacks that textbook RSA doesn't deal with.) Here, among some other numbers, the private key is the pair of prime numbers commonly referred to as p and q, and the public key is their product, n=pq, where n is referred to as the public modulus. Given p and q, calculating n is borderline trivial (you just need to multiply two -- very large -- numbers together), but given only n, determining the corresponding values for p and q is extremely difficult. We have no proof that this is so, though; only the absence of any publicly known easy way to actually do it, even with lots of very smart people having worked at the problem for a long time. It's like figuring out that 15 = 3 * 5, except that instead of numbers of a few digits, the numbers involved are many hundreds of digits. To a first order approximation, with your 4096-bit RSA key, n is about 1300 decimal digits long, and p and q are a little more than 600 decimal digits long each. We can see this because log10(24096) ≈ 1233, and 10615 * 10615 = 101230.

  If they can derive the public key, what algorithms can they use to do this? - I don't know.

Semiprime number factorization algorithms. The current state of the art for numbers larger than 10100 (100 decimal digits, about 332 bits) is the General Number Field Sieve (GNFS) algorithm.

A quantum computer could use Shor's algorithm to efficiently factor a semiprime, but (at least in public) we don't yet know how to build a large enough quantum computer that actually works. That's part of what the push toward so-called post-quantum cryptography is about. Last I heard, state of the art was having factored the number 15, but that was a few years ago; it is possible that publicly known quantum computers are now able to factor numbers larger than 15.

  What is the number (or order) of operations needed for each algorithm to derive the Private key?

The complexity of factoring a number using the GNFS is discussed on its Wikipedia page. It's really difficult to discuss the number of operations directly, but after some discussion on prerequisites, the Wikipedia article summarizes by stating that the running time of the number field sieve is super-polynomial but sub-exponential in the size of the input. You can compare the various factoring times and algorithms used for the various RSA numbers, which were part of a competition started in the early 1990s to expand the knowledge relating to integer factorization, now inactive.

Compare also How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it? Note that HTTPS works differently from SSH, but the basic operating principle remains similar.


How can we limit access to a single computer?

This can be simplified with some form of central management, such as using a directory/identity server that speaks LDAP or another protocol. This would only require a single CA in the ecosystem, and it prevents you from needing to set up access controls on each server individually.
On the directory server, each user is added, along with their public key and possibly groups that correspond to the servers they should be able to access.
When a client connects to a particular server, the web server (e.g. Nginx) initially checks that the user's certificate is signed by the CA. If the certificate is valid, the certificate's information is extracted and passed to the application. Then, the user can be looked up in the directory server, and their privileges/groups returned. Then, the server can check if the returned groups should be granted access, and proceed from there.
You can easily revoke access from the directory server to prevent further usage of the certificates.
Of course, implementing this will depend on your specific application and what tools you are willing to use. There may even be a ready-made solution out there.


Public API with authorization token -- is it possible to protect the demo token?

As Steffen has said you cannot protect the token from users.

I'd just like to add a suggestion for a more general scenario of having a "demo" Api. It sounds like your API doesn't have any stored data and just does calculations on input so this may not be a concern for you, but rather than having the demo token point to your real api, you could point it to a demo / sandbox version with meaningful, but not real data that could:

only have the demo token in it - no other users
be reset automatically on a daily basis
have a small amount of data in it rather than your full set (if you have data)
potentially not return valid results for all calculations as a way of requiring people get a real account from you rather than just using the demo token

This would feel safer to me as your live system would never be touched by anybody with the demo token, and in scenarios where you may have functionality you are selling etc, it allows developers to integrate and confirm they have integrated correctly, but doesn't give away the full set of functionality/data to the demo token.


WPA significantly less secure than WPA2?

Timing attacks against WPA TKIP have been successfull: http://www.itworld.com/security/57285/once-thought-safe-wpa-wi-fi-encryption-cracked

Also curtusy of @Iszi Japanese researchers in 2009 published a paper saying that they had been able to decrypt WPA-TKIP traffic:
http://pcworld.about.net/od/securit1/New-Attack-Cracks-Common-Wi-Fi.htm

If you are using WPA - AES no practical difference as you say other than bruteforcing or guessing password. Although unless you need it for backward compatibility why not use WPA2?


What are the benefits of shutting down a modem router when it is not in use?

Disconnecting internal devices from the internet when no connection is desired has the benefit that these devices are no longer externally accessible and thus attackable. While on the surfacet this seems "more safe", your devices are not really vulnerable unless they are either in direct communication with something or you forwarded some ports.

The risk to regular consumer devices from attacks over the internet is very small these days, assuming no risky behaviour from the user (e.g. downloading "free_M$_offic_[no_virus_100%_gurarantee].exe").

The downside is obviously you can't connect to your devices if you don't turn your modem on. This might now be a downside for you, if this is not a functionality you use.

I'll elaborate a bit on the points brought up in the comments:

  What does it mean for a device to be in direct communication or have ports forwarded?

In a normal home network, your devices are not directly reachable from the internet. Someone externally can connect to your home router (or router/modem/wifi-access point hybrid), but not directly to your home computer.

The router uses something called NAT, which basically means that your home computer can connect to a remote server and that server can reply, but once that communication is done, the remote server can't reach your home computer anymore. That's a gross oversimplification, but it illustrates the concept that others can only reply to you - they can't initiate a connection to your home PC.

In order for them to be able to do that, you need to configure port forwarding, which basically gives everyone a way to talk to your home computer (as long as that is turned on as well).

This means that if your computer does not have any active connections and no port forwarding is configured, it's essentially not reachable from the internet.

  What is the risk to regular consumer devices these days?

This would be a full question in it's own right, but I would wager that the average risk is rather small. A regular desktop PC, for instance, running a modern, up-to-date OS, will probably not have any publicly available exploits.

Even with other hardware you're likely to be safe, even if an attacker could remotely connect to them in some way. This includes smartphones, game consoles, smart watches, etc.

I'm not saying there is no way that these could have an exploit, because history has shown that there are plenty of exploits for modern operating systems. I'm saying the likelihood that an up-to-date product has a publicly available exploit is very low.

  But what if the vendor does not care?

Usually, if a vendor really does not care, the security community likes to make them care. Imagine you buy a router from GreedyTech, who only cares about profit and not about security. Some security researcher sees that router, and knowing GreedyTech's reputation, he buys it to analyze it. A week later, he finds an exploit and - like a responsible security researcher - he contacts GreedyTech. GreedyTech is not interested in spending any money to secure their products, so they kindly tell him to go away.

The security researcher tries again, explaining at what high risk they put their customers. GreedyTech does not budge, and again tells the researcher in no uncertain terms to "go away".

The security researcher then publicizes the vulnerability, hoping that it becomes as publicly known as possible. Why so? The researcher does this in order to:

Make customers of GreedyTech aware to buy a replacement as soon as possible.
Gather attention from the media, hoping that the bad publicity will force GreedyTech to improve their product or suffer from a bad reputation (and thus less money).

So in a sense, even if a product is highly insecure, it'll probably not stay insecure for that long.


Can session/cookie request token be sent via url?

The TLS will make sure it is encrypted in transit, so it will be protected against MITM attacks. But there are other reasons why this is a bad idea.

The token will be exposed in a lot of places. Server logs is a big issue, as you mention. Suddenly you will have to treat all your logs from where you terminate TLS and downstreams as security critical. Another issue is having the token exposed in the users browsing history, or even worse if they share an URL on social media. For an API that might be less of a issue, but if I had a penny for every time I have seen people expose authentication tokens when posting questions in support forums...

I understand why this might be a tempting design, but I strongly recommend that you just use a cookie or an Authorization header instead.


Sure it's possible.  Look at the NSA ANT catalog.  You'll find devices like COTTONMOUTH, which are implanted in USB connectors and allow for re-infection; DEITYBOUNCE which implants malware in a Dell server via BIOS and the RAID controller (flashing the BIOS should prevent this); GINSU which installs itself from a PCI bus device; IRATEMONK which is implanted in the firmware of certain hard drives; and IRONCHEF which replaces the BIOS (replacing the BIOS with a variant that reinfects a BIOS during the reflashing operation would be possible.)  And many of their other devices, like HOWLERMONKEY, can intercept your information without infecting your system.

While it may be possible, a second question is "is it probable?"  Is someone as sophisticated as the NSA digging into your computer?  I don't know you, so I can't answer that.  But since the NSA can do it, others have taken this on as a challenge.  The NSA Playset is a collection of Open Source projects that attempt to replicate some of the NSA capabilities.  SLOTSCREAMER is a PCI based attack device; ADAPTERNOODLE is a USB based attack device.  They haven't replicated the hard drive firmware attacks yet, but it's on their list.


Storing Bank Account information or third party services providing data store and payout service

A good option: don't do it.

The advice sounds dumb and you may have seen it in the posts you read but writing a secure application is not easy, you need to take zillion things into account.

Writing a secure application which will store sensitive financial information is not only difficult, but you now may run into liability issues. Depending on the country you may be responsible for losses of your customers after someone has hacked into your system.

You could either use some hosters which give you the ability to build an e-commerce site and maybe start from there, or have a reputable company writing it for you.

If you really, really want to do it yourself, start with OWASP. You also want to have a look at PCI-DSS. It is not exactly relevant in your case but the PCI-DSS SAQ-EP is interesting, it will hive you a hint on what is expected for e-commerce applications.

But really don't.


That's a generic recommendation to make use of Operating system hardening tools applicable to the underlying host.

I'd recommend reviewing the CIS benchmark for whatever host OS you're running in your virtual machines. Compliance with the areas of those benchmarks that meet your use case/threat model, should provide a good starting point there.


What's wrong with this authentication system?

I assume that the user ID are attributed randomly and uniformly among the 232 possible 32-bit values. In that case, the best an attacker can do is to try potential user IDs (32-bit values) in any order until a proper one is found. If there are N valid user ID, then the average number of tries that the attacker will need to perform will be close 232/(N+1): if there are one thousand of users, then the attacker will need to connect about 4 million times to your server before being granted access. Once the attacker gains access, he can reuse the ID at will.

Your only defence in that case is to try to detect such brute forcing, e.g. by banning IP addresses from which come too many failed attempts. This has limitations; in particular, when many people are behind some kind of Web proxy or NAT, they may, from your point of view, share the same IP address, so you risk disabling a lost of users with a lockout strategy. Conversely, attackers can rent botnets in order to perform their one-time brute force from a lot of distinct IP addresses.

One way to look at it is indeed to consider the user ID to be some kind of password; in that view, the attacker can attack the passwords for all users simultaneously. The security level is thereby lowered when there are more users, as can be seen in the mathematical expression above: more users means more targets for the attacker, without increasing the search cost.

A login+password strategy is what most people do. This is much better: when trying to brute force a password, the attacker must select a specific user name, and will be able to break only that specific password. The "user name" is a non-secret piece of information that is specific to each user. With user names, the attacker's task is no longer a thousand times easier when there are a thousand of users. As for a "session token", well, there are several methods which are more or less equivalent (token in the URL, token as a POST parameter, token as a HTTP header -- also known as a "cookie" --, and so on); SSL itself has its own notion of session and you could reuse that.

Summary: the "secret user ID" with no user name strategy can be secure, but only if the space of possible user ID is large enough to defeat brute force, even if there are many valid user ID. This requires large user ID which must be selected randomly and uniformly. 128 bits would be enough. 64 bits would make me quite nervous. 32 bits are way too small.


Is 'correct' TLS Configuration dependant mainly on the Server?

The server and the client are both important.   SSLLabs.com has a client test, as well as a server test.

There are more details in the How does SSL/TLS work? question, but quite simply, the in the SSL handshake, the client is the first to send the version of TLS it supports and ciphersuites it prefers, and then the server selects the highest version it can support and the ciphersuite to use.

So, yes, server configuration is extremely important, but you can see that client configuration is critical too.   Not only do you want to ensure that your client is capable of accepting (and prefers) TLS configurations that offer strong protection, but also that you disable weak versions and ciphersuites so that an attacker can't forcibly downgrade you to use insecure options for your SSL/TLS connections.


mitmproxy: Ignore host when ssl handshake fails

Turns out there is a way to do this. You just have to write an add-on script, and include the name of the script as an argument to the mitmproxy command. The methods in the script can control mitmproxy's behavior.

In fact, there's an example script in the Github repository that does the exact thing I wanted to do:
https://github.com/mitmproxy/mitmproxy/blob/master/examples/complex/tls_passthrough.py


Can XSS vulnerabilities present in 3rd party js libraries be used to attack the app that uses the lib?

Possible, but unlikely. Why?

Allow me give you some background information. I've seen people obsess over supposed "XSS vulnerabilities" in jQuery and many other libraries, here's one example:

$('#inputElement').keyup(function () {
   $('#someDiv').html($(this).val())
});

Some would argue that this code is vulnerable to XSS, which is not true. Yes, you can write JavaScript in the input field and have it executed (for example, <script>alert(document.cookie)</script) but so what? You can already do that with with any application that gives you JavaScript console (Firebug), heck, you can even do it with Greasemonkey.

It can be only considered an XSS vulnerability if data from outside your app is used inside your app by tricking the user into malicious URL or submitting a specially crafted form. Here's an example:

$(document).ready(function () {
   $('#someDiv').html(window.location.hash)
});

Now this is vulnerable to XSS, an attacker could craft the following URL

http://example.com/search/searchQuery+<script>alert(document.cookie)</script>

Or even use some URL shortening services to make the attack a bit more obfuscated. The point is, in such cases you need to worry.

If the client side of your webapp is using data from outside and it's possible that the legitimate user might not have control over it (like the case above), then you need to worry.

Another example using History API-fallback libraries, such as jQuery BBQ (it parses window.location.hash) which might be vulnerable and somehow allows code in the URL to be executed.

Please note that this answer is strictly in the scope of your question; XSS attacks related to JavaScript libraries.


If nmap shows all ports are filtered or closed, what would be the next logical step to take to get more information?

Checking for open ports using nmap only does a comparably dumb check if services are directly accessible on the device. In the default setup it will only check a few ports and thus will not find any services running on unusual ports.
But even when checking all ports it will not find services restricted to specific source IP addresses or protected by port-knocking or otherwise magic packets or packet sequences. Access to these services does not require physical access to the machine, but it requires specific knowledge about the kind of protection used and also possible secrets involved - none of this is involved by just a dumb nmap.
And even if no services are accessible on the machine it does not mean that physical access is needed. There might be outgoing connections from the machine where the response from some external server gets processed on the machine. This is done when reading mail on the machine or browsing the web but also when checking for updates or other automatic actions. Injecting an unexpected response might allow an attacker to attack the system from inside. But again, this requires no physical access but knowledge of what the system is actually doing and lots of knowledge about potential vulnerabilities in the installed software, OS, social engineering to make the user install some software etc.
And there is more which does not involve physical access: there might for example be vulnerabilities in the Bluetooth or Wifi stack which can be used to attack the machine.

...  what would be the next logical step to take?

Gain more knowledge about the system you are trying to attack, the installed software and its weaknesses, weaknesses of the end user etc. In a way it is like when you are trying to steal something: checking for open doors (nmap) is only a very simple step and very likely the doors are closed. But there might be weak locks, windows, gullible residents which open the door for you etc.


Everything that goes through HTTPS is enough as long they use a certificate trusted by your browser. This means it was forged by 3rd-party acknowledged authority of certification.

If they use their own certificate. You may reconsider that statement.


Why does switching to "n-only" help preventing attacks on WPS?

Switching to “n-only” help preventing attacks on WPS because some hackers don't have n adapter :). It doesn't matter n-only or mix mode enable on your AP. You should turn off WPS.. but some devices don't have this feature :(. I have cracked a few AP (n-only mode) and haven't had any problem with cracking.


Is it possible to boot an encrypted server remotely and securely?

Microsoft's 3rd immutable law: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." So you have to trust the people running your data-centre. That's what trust means in information security: it's what you are reluctantly forced to do when you can't fully control, avoid, or transfer a risk.

Still, you will want to put as many controls in as you can. In this case, a TPM module is probably your best bet - the key is burned into the silicon of the chip when it's made, and so is very difficult to extract.

Windows and Linux both support TPM based full disk encryption; so does VMWare ESXi, which would also give you OS independence.

Lastly, @hopelessn00b et al point out something I should have remembered - the remote management cards you can get on enterprise-class servers use strong encryption. That's a great way to get ssh access to the console in hardware, so you don't have to mess with the config of your box.


How to get the IP Adress of an email receiver

You can pixel all you want, but they might get a message in their mail client saying that "images" or "external content" has been blocked, and they'll have to manually allow it, which might be suspicious to them.

Something I used to do is forge a story inside the situation (add a bit of social engineering to the pixel idea).
What I would do in this situation would be to send him an email:

I found a picture of a piece of land I'm willing to buy, please see below:
<img src="http://my.server.com/image.jpg?tag=827362923">

Then, you wait and later on search the web server logs with grep 827362923.

This has a few limitations:

Chances are the image gets picked up by antispam on the way, so you might get false positives that hit the link, you can check this with WHOIS (e.g. https://whois.domaintools.com/[enterIPHere])
The receiver still has to allow images to load in the mail client, but in this context, it's less suspicious than with a pixel.
It requires you to have your own server.
If the scammer is behind a VPN or proxy (which is very likely in most cases), you will obviously get that IP.


The PGP trust model has a transitive computation model: when a key is trusted and valid (as certified by other valid and trusted keys), it is itself considered for determining further valid keys.

This does not really match either of your options, as "introducer keys" are usually considered those forming "validation roots", for example your own key. GnuPG uses the "ultimally trusted" term for those. Usually that's your own key, as everything else can by expressed by certifications and issuing trust.

The default PGP trust model is "A key is valid if it has at least one certification by a fully trusted and valid key, or at least three certifications of marginally trusted and valid keys." GnuPG adds a path length limit of five certifications from ultimately trusted keys (or "trust introducers").

The GnuPG manual provides an illustrative example on the web of trust and trust calculations, and I discussed GnuPG's output on trust validation in another question which might provide further insight if you're already having your own keyring.


How hypervisor rootkits create network connections?

From the paper SubVirt: Implementing malware with virtual machines.

  This new type of malware, which we call a virtual-machine based rootkit (VMBR), installs a virtual-machine monitor underneath an existing operating system and hoists the original  operating  system  into a virtual  machine.

There are two main approaches for making a suitable running environment for the rootkit:

The first one involves changing the actual operating system and user programs with your elevated authorization and running the VMM (Virtual Machine Monitor) and user/kernel mode component of the rootkit.
The other one is pretty much the same, just using another operating system.

  Further, VMBRs support general-purpose malicious services by allowing
  such  services  to  run  in  a  separate  operating  system that is protected from the target system.

You can use APIs (including the TCP/IP stack and related API) and the hardware abstraction of your new host. It is a little different, but I must say another way is using your own TCP/IP stack:

  Delusion comes with its own TCP/IP stack based on lwIP

The Blue Pill-based Delusion backdoor uses its own stack according to the Introducing Blue Pill presentation.

And what about if our new host application need to interact with target OS? For stealing data in the first place.

Like most of the legit virtualization software you can use agents inside  the guest OS.
Controlling CPU registers makes it easy to implement any hooking techniques.
The hypervisor also controls the disk and the OS interface to the disk.

This is another topic to discuss, but it is more than enough to control the target OS.


I'm not fully sure what you mean by offline mode but I'm going to guess you mean offline PIN verification. The PIN can be validated within the terminal based on the PIN entered by the customer and the PIN on the Integrated Chip within the credit/debit card. This is not a DUKPT related process and offline for this process is fine.

DUKPT will be used to provide a key management system whereby sensitive data from each transaction is encrypted using a specific and unique key. Once a key is used a counter increases such that the appropriate KSN (Key Serial Number) and related key can be identified for decrypting the data later on. The next transaction will use the next available key for encryption.

I'd suggest reading up a bit more on DUKPT functionality (search DUKPT on google) to cover Base Derived Keys (BDK), IPEK and Future Keys. Chip and PIN terminals will often be loaded with thousands of keys to permit DUKPT. Without DUKPT a terminal is more likely to use a static symmetric key for encryption and public keys for signing transactions.


Using different host key algorithms on sftp server and client

(After Q edit)

In SSHv2 (the only one anyone still uses) yes, both the (selected) host key and the client key if any are used only for authentication; the client software must support receiving (and verifying) the host's key type (in your example EC) and the host software must support receiving the client's key type (RSA).

The session key is created using ephemeral Diffie-Hellman (including ECDH or X25519 in modern systems) not the user-visible 'pubkey' files and algorithms, and the two data ciphers (and MACs if applicable) are negotiated separately and use working keys (and IVs if applicable) derived from the session key.

This is mostly described in RFC 4253 especially 6.5, 6.6, and 7. Some options are in other RFCs; see https://en.wikipedia.org/wiki/Secure_Shell#Standards_documentation or http://www.openssh.com/specs.html .


Sufficient to only install security updates on Debian?

That should be enough, until they announce that the version is so old that it won't be supported anymore (at which point they'll stop providing security updates). Since this is one of the newest releases, you should be fine, at least until 2022 if this table is accurate.

Think of it this way: if it wouldn't be enough for security, why would they continue to provide security updates?

Of course, just installing security updates doesn't prevent you from making your system insecure by other settings (weak passwords etc.), but in that regard there is no difference between 10.3 and 10.4.


How does end to end encryption work with whatsapp web?

Correct: The Web-Client is establishing a secure connection to the phone. The messages you send through WhatsApp Web are encrypted by the WebClient, decrypted by the phone, then re-encrypted to fit the end-to-end scheme and then sent to the recipient. Same thing the other way around.

I dont know details about the protocol, but this is what i suspect (or how i would implement it):

When first opening WhatsApp Web a key pair for asymmetric encryption/signing is generated (and stored in the local storage of the browser. Probably RSA or ECC.
Scanning the QR code exchanges the fingerprint of the said keypairs public key. This establishes trust between phone and browser installation: the fact that the user scanned the QR code implies that the user trusts the browser.
When WhatsApp Web is to be used, a TLS connection to the phone is established (probably proxied by WhatsApp to overcome Firewall and NAT issues). WhatsApp Web authenticates towards the phone using the initially generated keypair (thus relying on the trust established earlier).

The connection between the Browser and the phone is fully qualified TLS: Authentication and PFS included.


Reflection? Not unless the system has failed to patch MS08-068.

Relay? Yes, NTLMv2 is vulnerable because of SMBv1/v2. Here are details on that attack -- https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/november/introducing-chuckle-and-the-importance-of-smb-signing/

The SMB Relay and NTLM Relay attacks are thwarted if SMB signing is enabled, if Enhanced Protection for Authentication is enabled, or if all clients are Win10 while all servers (including domain-functional level) are Server 2012 R2 or higher. See more in this answer -- https://security.stackexchange.com/a/139578/140


Is logging in using OAuth/OpenID also vulnerable to heartbleed?

OAuth and OpenID don't send your password to the sites you use OAuth/OpenID providers to login with, so no. Not unless the attack is performed on the OAuth/OpenID provider and provider's servers are vulnerable to CVE-2014-0160 (The Heartbleed Bug). It is however possible, of course provided that sites you're logging into using OAuth/OpenID providers are vulnerable to Heartbleed, that other information could leak, like say your email address, or user session information with which it could be hijacked for the duration that it is valid for.


Can vulnerabilities in libraries cause security problems in user-level binaries?

Let's talk specifics.
A version of libxml (the first item in your list) has a CVSS score of 10 allowing for a buffer overflow leading to remote code execution and denial of service.
Let's assume that the binary that used this library is not run with elevated permissions.
Now let's re-ask your question:

Does such a vulnerability cause security problems?

Quite obviously yes.

The DoS is a security problem in that a remote attacker can stop the service at will.
Exploiting the vulnerability remotely allows an attacker to run commands as the user the binary was run as. You do not need to be root to do damage or to gain unauthorised access.

Not all vulnerabilities are about gaining root/system access and "total pwnage". Security is not "all or nothing". However, depending on how the system is designed, it is also possible for the misuse/abuse of a non-privileged account to result in privileged access.


The license generation method isn't really that important, as long as it's non-trivial. The trick is how your client verifies that the license is correct.

Let's say you do something like this:

BOOL verifyLicense (char* licenseKey)
{
    BOOL result = false;

    if(strlen(licenseKey) > 128)
        return false;

    char* url = (char*)malloc(1024);
    sprintf(url, "%s%s", LicenseServerBaseURL, licenseKey);

    char* response = http_get(url);

    if (strcmp(response, "OK") == 0)
        result = true;

    free(result);
    free(url);
}

This is pretty simple - we do some basic checks on the license key, create a URL that contains the license key, then do a HTTP GET to the server to check the license. If it returns "OK" we accept it.

The problem with this is that anyone can disassemble the client:

 ...
 push 06f2011c        ; address of url string
 call http_get        ; http_get(url)
 mov ebx, eax         ; store a copy of the result address
 push 04830040        ; ASCII "OK"
 push eax             ; address of response string
 call msvcrt.strcmp   ; strcmp(response, "OK")
 test eax, eax        ; if( ^ == 0 )
 jnz exit             ; skip if branch if non-zero
 mov eax, 1           ; result = true
exit:
 push ebx
 call msvcrt.free     ; free(result)
 push 06f2011c
 call msvcrt.free     ; free(url)
 ret

All I have to do is alter the jnz exit to a series of nop instructions, so the jump is never taken and the result is always true. That way, any license key is accepted. Even better, I could simply modify the start of the method to immediately set eax to 1 and return, so it never even bothers to ask your server for license validation.

So, how do we solve this problem? Unfortunately for you, we can't. You're running into the DRM problem, which essentially states that if you hand someone some data, they can always change it. No matter how much you obfuscate your code, it's possible for the user to eventually reverse engineer it and work out how to make changes, or extract data. If you encrypt content, you eventually have to have the key on the system in order to decrypt it, so there's always a way for the user to extract that key and decrypt the content permanently.

The best you can do is make it difficult, which involves a lot of time and effort. Eventually your software will be cracked and end up on a torrent site somewhere. It sucks for developers using this kind of business model, but it's the world we live in. My suggestion is that you go down one of two routes:

Create a basic licensing system that works, and accept the fact that some people will pirate it. Serve your real customers by spending your development time actually making improvements to the software, rather than implementing and maintaining draconian DRM systems.
Alter your entire development and business paradigm, so that your product is a service rather than a software application. SaaS has been very successful, since it's (practically) impossible to pirate services, and the model allows you to make real-time changes to your codebase, and perform analytics on usage.

If you go for option 1, don't involve a server for validation. It adds complexity, provides no added security, brings some privacy concerns, and makes it impossible for your users to use your software if your licensing server is down. Just stick with something simple, e.g. a hash of the username and a secret value on the client side. It's trivial to break, but it gives a minimum barrier to piracy.


There is no huge security weaknesses with them. Actually, a lot of websites (banks notably) are already using web rendered keypads as part of their customer's website authentication mechanism.

While there is still pros and cons, this offers the developers more flexibility than using standard OS input. In particular, the numbers can be presented in random order (preventing shoulder surfing) and it can be made impossible (or at least difficult) for the end-users to copy-paste the password or make the browser remember it.

The main argument I saw against such systems is a direct consequence of the anti-copy-paste feature, since it also prevents the use of password safe software to securely store the password. But this is not a weakness of the HTML rendered keypad per se.

As you said, all attacks valid against the former could also be done against the latter in one form or another.


Can I use PBKDF2 derivation function to generate a MAC in PKCS12 file?

NO. (sorry)

Actually you need all of B not just B.2, and if you try to implement this note the formulas in B.2 step 6 have errors; see https://www.rfc-editor.org/errata_search.php?rfc=7292 .

See section 4 item 3:

  ... if [MAC] present ... As described in Appendix B, the MAC key is
         derived from the password, the macSalt, and the iterationCount;
         as described in Section 5, the MAC is computed from the authSafe
         value and the MAC key via HMAC [11] [20].   ...

No alternative is allowed for.

Although I don't think it's clearly stated anywhere, the AlgorithmIdentifier in the DigestInfo identifies the hash used in the PBMAC, not the PBMAC itself; in fact it can't identify the PBMAC as there is no OID defined for this PBMAC, whereas there are OIDs (in Appendix C) for the 'password privacy' (encryption) schemes (and also parameters suitable for an AlgorithmIdentifier). Thus there is no place you could provide the information about an alternative PBMAC that the recipient/reader needs to know about and use. (Whereas your PKCS8 shroudedkeybag(s), and also PKCS7-encrypted certbag(s) if you follow the usual practice, can have PBES2+parameters in their AlgorithmIdentifier.)

Confirming this, appendix C says:

  This section is here for two reasons: first, to enable backwards
     compatibility as described in the first paragraph of this section;
     second, because it is still used in password integrity mode.  In
     order to not use it in password integrity mode, the ASN.1 definitions
     require updates.  This document recommends that future definitions of
     the PFX structure replace the existing MacData object, optionally
     present in password integrity mode, with a new object definition that
     holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication
     scheme.  This change would simplify the requirements for key
     derivation functions used across all parts of the PFX structure.

which explicitly says your idea is a good one but not presently possible. This paragraph is added relative to the RSALabs original document, and is almost the only such substantive change.

Also, a nit: the MAC doesn't cover the 'whole file', only the AuthenticatedSafe. This excludes the version and the ContentInfo 'wrapper' (tags & lengths & OID), and of course excludes the MAC itself and the outer SEQUENCE tag & length.


Does AWS store users' passwords without hashing?

Checks if the account password policy for IAM users meets the specified requirements indicated in the parameters.

What is being checked is the account password policy, not the actual passwords of users.  It's a periodic check to make sure you're requiring the level of complexity that you want to be requiring.  As such, no need for reversible encryption of user passwords.


Are complex passwords necessary in web applications?

Assuming that you have every popular brute-force prevention technique in place. You are still a web service that serves users. So, you must allow some leeway in login procedures.
Now, login brute force attacks are most likely to be targeted at high-value targets so an attacker would probably be committed to compromising your account.

Assuming an attacker can try 10 passwords every hour (Probably stricter that any regular web service), it is still possible to try 7200 passwords per month from a single attacking endpoint. Now consider a dedicated attacker with more than one computer attempting to log in to your account.

This makes passwords such as applefreezer that would be close to the top of password lists, somewhat vulnerable. Depending on the value one would assign to his/her account on that specific web service, that may be tolerable or not.

So there are reasons why strong passwords should be used anywhere, no matter the other defenses. But if you are not a high value target then yes, brute force mitigating techniques are a pretty solid defense, even with a weak password.

TL;DR: You are right, brute force mitigations are enough to allow you to use a weak password. But since brute force is usually targeted at high value targets, an attacker will be patient enough to try long enough and break weak passwords.


Storing a user's password in a retrievable manner

It looks like you want a back door and that you're not concerned with privacy or legal consequences.

Two recent stories to provide some context

2013: Lavabit intentionally lacked access to its users' content so that it could not be accessed by a court order.  When the NSA figured out that they could get it by demanding the server's SSL private key and reading all traffic (rather than that of the user in question, Edward Snowden), Lavabit decided to shut down rather than risk compromising the security of every single user.

2016: The Apple vs FBI debacle is a similar story, playing out right now, about the foolishness of back doors.  I've chosen to link a summary of comedian John Oliver's explanation of the issue because it is rather well composed.  That link also features Oliver's 18 minute HBO feature on this issue, which you can watch directly at Last Week Tonight with John Oliver - Encryption

If you still want to do this

PGP supports multiple recipients, which I'd recommend over actually saving the password.  This will let you encrypt data to a server key in addition to a user-specific key.  Please note that it would be highly irresponsible to not advertise that you're doing this to your users.  It might even be illegal.

Implementing this is as simple as specifying more than one recipient in GPG or whatever implementation you use.  For example:

gpg --encrypt --recipient user@example.com \
              --recipient server@example.com message.eml

Depending on your intended use, this probably requires storing the server's private PGP key without a password, which is a problem in itself.  If possible, try to use a hardware-based system like an OpenPGP card or at least require a human to unlock the key at each boot (with failovers to your code that accept that the server private key might not always be loaded).

Again, this is a back door and is not advised since it is still subject to subpoena and hackers (though an OpenGPG card or similar hardware key should prevent remote attacks).

It would be vastly preferable to find some other solution to your issue.  Since you haven't spelled out what you're actually trying to do, this community won't be able to help in that regard.


Do any third party time stamping signature services exist?

A line from a build script I used a few years ago:

signtool sign /v /f <REDACTED> /p <REDACTED> /fd sha256 /t http://timestamp.verisign.com/scripts/timstamp.dll %1

That is, using the Windows SDK's signtool.exe to request that Verisign (now Symantec) timestamp the signature of the file I was compiling. Ironically, the domain timestamp.verisign.com is unavailable over HTTPS (although this doesn't really matter; no meaningfully sensitive data was being passed and I could of course verify the timestamp signature against a known key).

You may be able to find other public timestamping authorities; that's just one I was shown by somebody else working on a similar problem. Also, note that signtool.exe has a separate parameter (/tr vs. /t) for RFC 3161 URLs, which suggests that the URL I provided is not RFC 3161 compliant.


You might want to take a look at the Canari Framework (https://www.canariproject.com/4-3-transform-development-quick-start/). It's an awesomely simple transform development framework that let's you do some pretty rad things ;).

UPDATE 1:

Canari now has some additional support for complex field types. So far we've added datetime, timespan, color, and date. You can design an entity like so:

@EntityField(name='mydate', type=EntityFieldType.Date)
@EntityField(name='mydatetime', type=EntityFieldType.DateTime)
@EntityField(name='mytimespan', type=EntityFieldType.TimeSpan)
@EntityField(name='mycolor', type=EntityFieldType.Color)
class MyEntity(Entity):
    pass

And use it like so:

import datetime
e = MyEntity('value')
e.mydate = datetime.date.today()
# ... etc.

Hope this helps! Support for array types and other things coming soon. Also, if you are curious how to format things, simply design an Entity in Maltego with the various field types and see how it renders the property values in the property editor once you drag your entity onto the graph.


How do I learn Cryptographic/Mathematical notation

One approach is to read a good crypto textbook.  I highly recommend Cryptography Engineering by Ferguson, Schneier, and Kohno.  You could follow the notation they use in that book, and that'd be one reasonable way to go.  (You'll learn lots of other practical, useful stuff along the way.)


Check reputation of specific email address

What does the security community use to find information on the reputation of specific email addresseses?

Nothing. This isn't a subject of interest.

Email addresses generally fall into two categories:

Major webmail providers. Abusive activity from these addresses is best handled by forwarding the emails to the provider's abuse address, not by adding the address to a blacklist. They tend to respond quickly.
Private mail providers. If the provider does not follow up on an abuse report, or refuses to take action, the most appropriate response is typically to blacklist the domain, not the address. If the provider is malicious in their own right, they can create a practically infinite number of addresses under a domain they control; there's no point in trying to block individual addresses.


Can I slow down a brute force attack by encoding password input data?

Yes, you can artificially slow down a brute-force attack by having the client perform an expensive task for each login attempt. This concept is called a proof of work. It's a well-known approach to fight mass spam and technically you could also apply it to authentication systems on the web.

However, your concrete proposal wouldn't qualify as a proof-of-work protocol. That's because base64 isn't expensive at all and requires an equal amount of work for the client to generate as it does for the server to verify. Also, an attacker could reuse the encoded passwords as often as they like without having to recompute them, e.g. to attack other accounts.

For a real proof-of-work implementation, you could e.g. build a challenge-response scheme and require the user to perform expensive hash computations on each login attempt. The challenge could be to partially invert a hash: You provide a random sequence and challenge the user to generate a SHA-256 hash ending with that very sequence. Increasing the length of the sequence requires exponentially more hash computations by the client but verifying the results is always just a string comparison.

The project "proof-of-work-login" is one of the few real-life examples I found that pick up the idea of using a POW for logins. (I can't comment on the quality of the implementation though.) From the description:

  A client side SHA256 hash must be calculated before allowing a login. This limits bruteforce login attacks in environments where you can't ban by IP like Hidden Services.

Nevertheless, you should bear in mind that for web applications there are simpler means to obstruct brute-force attacks such as CAPTCHAs, limiting login attempts per account,  blacklisting IPs, etc.


How to prevent email discovery in forms?

This can be solved by implementing an out of band message.

To solve this issue I would have a form which can be used for two purposes:

Account recovery.
New user sign up.

The single field on this form is Email address. Of course you can use different text depending on whether the user wanted to recover their account or sign up, but the way it works will be the same.

Once the user has entered their email address and clicked Next, the same response will be shown for any address entered. Something similar to Thank you, please check your email account for the provided address.

The "out of band" message sent their email address will either say Please follow the link to recover your account or Please follow the link to sign up to our service and will contain the appropriate links which will include a time-limited token to allow the user to recover their account or sign up as necessary. The only thing that determines the text of this message is whether an account exists for their email address within the system, it does not matter if the user followed the account recovery or new user sign up links. As they should be the only user that can read their email, this should prevent username enumeration.  The token will be associated to the provided email which will stop the user then attempting to sign up using a different address, or to reset the password of any other account. This also has the effect of validating the email account for new sign ups.


SSL cert securing an on-premises web service where the domain is hosted externally

Yes, this sounds like a normal way of doing things.

Step 3 will be via a DNS A record pointing mobile.abc123.ie to your external IP with the 443 port forward.

You could consider SSL offloading on your firewall if it is supported for increased performance and scale if that is a concern.


How do password suites store and encrypt their metadata and prevent attacks based on that knowledge?

I use KeePass Password Safe. This password manager stores all passwords (and related metadata) in a AES-256 encrypted database. When the correct key(s) is (are) provided, the entire database is decrypted and ready for use.

So besides a quality cipher, it's crucial that sufficiently strong keys are used. Provided that's the case, the time needed to perform a brute force or dictionary attack rises exponentially with the length of the key(s).

KeePass makes brute-forcing the password database harder (take more time) by encrypting the key N rounds. The recommendation is to choose the value N so that decrypting takes around 1 second on typically used hardware, which makes brute-force and dictionary attacks take N times longer to complete. On recent hardware, N is usually larger than 10 million.

See KeePass Security for additional information.


What's the point of a digital certificate for which no private key exists?

If my understanding is correct, without a CSR there can't be a link to a private key

Your understanding is wrong.
The CSR contains the public key and is signed by the private key. The private key is kept private by the owner of the certificate (which is not the CA). It is not given to the CA inside the CSR. The CA also does not need the private key but only the public key since the public key is ending up in the final certificate.


How can bulletproof hosting be feasible?

Spamhouse can't block subnets at least not a 100% reliable. They can add subnets to their DROP list which can but is not nessecarily followed by every backbone provider. The decission to apply the DROP list is up to the provider.

In most western countries there is a conflict between security and freedom. As a constitutional state they need a legal basis to force someone (Backbone providers in this case) to do something. Implementing a law that provides the ability to censor specific websites or even complete subnets often stands in conflict with the constitution of these states. So its mainly a legal issue and a question of proportionality.


What does mov qword rbx, '//bin/sh' mean?

I understand that a qword is a data of size 64 bits but when I remove qword the shellcode doesn't work. Why I need to add qword?

Because you're moving a qword constant. When you type '//bin/sh' you're expressing an 8-char array. By prefixing with qword you're instructing the assembler to treat the right hand operand as an inline 64-bit integer. By default it will probably treat it as a pointer to that string, or some other behaviour.

And after the instruction shr, my strings should be looks like '%00//bin/s' no?

Integers on x86 architecture processors are stored as little-endian. If your compiler took it literally, your string would be encoded in ASCII as follows:
/  /  b  i  n  /  s  h
2f 2f 62 69 6e 2f 73 68

Which you can also show in the following instruction:
mov rbx, 0x2f2f62696e2f7368

This encodes as follows:
48 BB 68 73 2F 6E 69 62 2F 2F

We can split this up into 3 sections:
48        BB                     68 73 2F 6E 69 62 2F 2F
|         |                      |---------------------|
 \         \                             literal
  64-bit     B8 = MOV instr
  prefix        + reg operand
                + r/m operand

In this case the mov instruction byte (BB) also contains a 7-bit field which describes the register we're moving into (rbx) and the type of right-hand operand (literal).
But note carefully: the literal is not in the same order as the ASCII representation we saw above. Instead it is reversed due to little-endianness.
The problem here, of course, is this can't possibly be what happens in your shellcode. If the name was reversed in the bytes then the function you call would see hs/nib// and fail. Instead, your assembler is smart enough to realise that you want those ASCII characters in byte-order, which means it really encodes the following instruction:
mov rbx, 0x68732f6e69622f2f

This produces the following encoded instruction:
48 BB 2F 2F 62 69 6E 2F 73 68

As you can see, the // comes first (2F 2F) in the byte-order representation.

Why not use shl instead of shr?

You do both. Your code is missing an instruction, which can be seen in the tutorial. After the shl rbx, 0x8 there immediately follows a shr rbx, 0x8.
Their explanation does it justice:

After shifting 0x08 to the left (think of each numeric placeholder in the string as a 4, so moving 8 bytes over actually moves us two spaces) pushes the 11 right off the end. Now we have this:
0x68732f6e69622f00
Then we put it back like before by using shr by the same value, and we get this:
0x0068732f6e69622f
This successfully gives us our string terminated by a nullbyte without generating a single nullbyte in the machine code.

The first slash is simply a sacrificial character which gets discarded during the shl.
The reason for this trick instead of just loading the null in the first place or masking the rightmost byte with zero is that it requires no null-bytes in the exploit payload, which is very useful if input is ignored after a null (e.g. if a string is being copied with strcpy).


Where does authenticity fit into the CIA Triad?

I support David's view that if you had to fit your scenario into one of the CIA categories, integrity would be the appropriate one because you're creating an unintended state thus violating integrity.

But also have a look at the Parkerian hexad which is a popular extension of the CIA triad. It consists of the attributes confidentiality, possession or control, integrity, authenticity, availability and utility. In this model, writing messages in the name of  another user would fit into the authenticity category.

Also, you might want to think of the CIA triad mainly as overall security goals. But it's not necessarily a powerful tool to classify specific vulnerabilities.


Your problem, as I understand it, is that you want to ensure that userID and messageID are an at least plausible pair in your front-end before touching the database.

I think about hashing userId and add the hash as prefix of messageId.

Assuming you mean URLs like /user/uuuuu/message/hhhhhmmmmm, where uuuuu is a user-ID, hhhhh is a hash of that user-ID, and mmmmm is a message-ID, then – even if someone doesn't know what hash algorithm you are using – once they see a valid uuuuu/hhhhh pair, they can spam you with any mmmmm following the hash prefix, and it would look "OK".
What I think you need to do is verify both the user- and message-IDs. In addition, to guard against someone discovering which hash algorithm you are using (and thus being able to generate their own verification strings), you want to include a "secret" that is only known to your back-end.
Creating a URL

For a given user-ID uuuuu and message-ID mmmmm form the string sssssuuuuummmmm, where sssss is a secret string.

Create a hash of sssssuuuuummmmm and call it hhhhh.

The resulting URL is /user/uuuuu/message/mmmmmhhhhh (it doesn't really matter which end you stick the combined hash; I've put it on the end because it feels more natural).

Verifying a URL

When your front-end is given /user/uuuuu/message/mmmmmhhhhh, form sssssuuuuummmmm using the same secret as before.

Hash sssssuuuuummmmm and compare the result with hhhhh from the URL.

If they match, then uuuuu and mmmmm are probably a valid pair of IDs and you can check with the database.

Depending on the level of false-positives you want to have to deal with, the hhhhh can be an abbreviated form of the hash. This answer to the question How much can you truncate a SHA1 hash and be reasonably sure of having an unique ID? on StackOverflow suggests at least 45 bits: 64 for safety. An 8-byte hashlet would be 16 characters of hex, which should be manageable, although for your situation you could go even shorter, at the risk of an occasional unnecessary database access.


How do I secure X server against spyware in a GUI application?

As an immediate patch, you should run such an application in a separate X server on a different VT. This is the only way you can guarantee that the app does not use the X API to spy on other clients. You may also try your hand at XSELinux but I know of very few people in the world who know how to run it, and it usually severely limits what your target app can do (not to mention the cost of labelling your desktop's data properly).

Besides, you still need to prevent process code injections or introspection, and to prevent the app from tampering with your users' runtime environment by sandboxing it (you need mount and IPC namespaces at least). See Docker and MBox. Note that I don't discuss exploits against the kernel / namespaces / X servers, just available Desktop capabilities.

On the longer term, display protocol like Wayland that guarantee isolation between clients from the start will be available. Until then we must cope with the insecurity of the Linux desktop.


How is leaving a telephone on the ground a "classic anti-surveillance technique"?

What surveillance does leaving a telephone on the ground while walking away counter?

If the mobile phone is compromised and acting as a covert listening device, also known as a "bug".  To walk away is so that conversations are too far to be properly heard.

Nobody needs to actually use the phone and make a call for such surveillance to happen, it is just a thing that sits there and collects every sound around it.

Examples

Remotely turning on cell phone microphones, from 2012:

  a judge published a statement that the FBI's established practice of remotely turning on cell phone microphones to monitor conversations was indeed legal.

Source: What are prudent security precautions to take for business travel by people with access to sensitive info?

Even smartphone gyroscopes could be re-purposed into microphones:

  When the researchers tested their gyroscope snooping trick's ability to pick up the numbers one through ten and the syllable "oh"—a simulation of what might be necessary to steal a credit card number, for instance—it could identify as many as 65 percent of digits spoken in the same room as the device by a single speaker.

Source: https://www.wired.com/2014/08/gyroscope-listening-hack/

Further examples: https://www.schneier.com/blog/archives/2006/12/remotely_eavesd_1.html

Other parts of your question

Without further clarifying details from the lawyer, most likely:

  I am curious as to how leaving a telephone on the ground in the street

The ground and street are just due to where this occurred, not specific to understanding the walk-away approach.

  is considered [a] "classic anti-surveillance technique".

The classic is an adjective to describe the anti-surveillance technique, that it "has been done since long ago", implying "everybody" "should already know this". Then the lawyer can say that it is "obvious". From there, how such "obvious" things were missed, so that along with satisfying other requirements, the lawyer can establish that there was negligence and win the case.


Netasq has a firewall feature that targets specific applications using deep packet inspection not just basic port blocking. In order to bypass the firewall you would need to encrypt your traffic by using a VPN or similar. I good vpn client is called OpenVPN. To accomplish this through ssh(using linux) you would ssh -D 8080 user@example.com you would then need to run ssh -L 1234:127.0.0.1:8080 user@example.com The first command sets up a proxy(socks) service on port 8080. Then second command binds a local port to the remote port on the server where proxy is running. After a while ssh session will drop due to no data being sent over the connection. To keep connection alive you would need to add

ClientAliveInterval 120

TCPKeepAliveyes

to the ssh daemon config file usually located at /etc/ssh/sshd_config on the server. If you don't have access to the sshd config file you can also use

ssh (commands here eg. -D or -L) -o TCPKeepAlive=yes -o ServerAliveInterval=60 user@example.com

The command above would have the same affect keeping the connection alive.

If you are using putty(ssh client) click connection on the left panel you will see seconds between intervals and a text box enter 60 in the text box this will keep the connection alive and stop it from dropping out. Putty also has port forwarding options under Connection -> SSH -> Tunnels. To create a proxy on the server you would need to enter -D 8080 user@example.com under Connection -> SSH where you see remote command. This will setup a proxy(socks) on port 8080 on the server. After setting up port forwarding and proxy you would need to configure torrent client to use the proxy listening locally.
A torrent client will still work if the firewall does not allow incoming connections to ports.


Is HTTPS + FacebookID + Secret Header token sufficient for a user login?

If it is server-to-server and you control the server that might be acceptable. But if this API is used from the client, No this is not OK.

HTTPS will secure the secret from third-party eves-droppers but not from the user himself. Since the user controls the computer, they decide what certificates are trusted, and can install their own man-in-the-middle. There is even a free tool which does this known as Fiddler - used primarily for debugging purposes it can install an HTTPS certificate into the certificate store and use it to MITM all communications.

Therefore it is trivial for any computer user to find out the APIKEY, and then every other user is pwned. Not Good.

For marketing: "This would allow any technical user to discover the APIKEY and they could then access the data of every user."


Are there established and/or curated security benchmarks/best practices for home appliances and networks?

While I'm not aware of any actual, certified standards, there is no shortage of recommendations from national organisations such as NIST, CESG, Anti-fraud agencies and the like.

StaySafeOnline is from the US National Cyber Security Alliance
US CERT has a home and business section
SANS have a document called Cybersecurity Inventory at Home
The UK's CESG have the excellent 10 Steps to Cyber Security, not really home specific but great advice anyway.
The UK police ActionFraud site has great advice.
The UK Government's CyberStreetwise site might also be useful
ISC2 the training and certification org have some useful tips.

There are many useful blog posts as well of course.

In addition, there are various courses such as FutureLearn's Cyber course (FL is part of the UK's Open University and their courses are free). They also ran an excellent Introduction to Cyber Security course that was created in conjunction with the UK's Cabinet Office - not sure if they will run that again.

UPDATE: I realise now that I only answered part of this question. As @blownie55 points out in his answer, some architecting of the network is in order to try and isolate more vulnerable IoT devices from other services. Any diagram on enterprise networking would give you an idea as to how this goes.

You need to separate out some networks and try to isolate traffic within them, restricting any traffic that might need to span the networks. For this, you need a decent router/firewall.

Typically in a home, you will only have a single router/firewall which sits at the edge of your LAN and provides the link to the WAN. Now we need to add additional router/firewall configurations inside that initial LAN creating sub-LANs with largely isolated traffic.

You can do this by buying more routers or by adding 2 network cards into a PC and running it as a router/firewall. But this is rather costly.

Alternatively, you could buy a decent router/firewall such as the Ubiquity EdgeRouter Lite which allows you to create isolated subnets in software. Unfortunately, as Ubiquity do it right, this requires a managed switch rather than a cheap unmanaged one. The EdgeRouter Lite only has 3 Ethernet ports so you can only create 2 LAN's. Ubiquity also make routers with more ports though. I only mention Ubiquity because I've used them and they come with pro-level features for a home router price, I'm sure there will be others that can do all this.

Once set up, the EdgeRouter OS allows firewall settings for each LAN route.

You can do this with Wi-Fi as well. Since Wi-Fi will never be as secure generally as a wired network, you can use a decent Wi-Fi access point that has it's own security or that you put onto its own VLAN to isolate the traffic and prevent access to any key resources you want kept extra safe.

UPDATE 2: Apologies that this is getting a little long.

If faffing with routers is too much. One much simpler way to help isolate IoT devices would be to put all of them on a subnet that is different to your main LAN subnet.

So let's say that your Internet router is 192.168.1.1, it is likely that it automatically creates a LAN on 192.168.1.0-255 (a netmask of 255.255.255.0). But you don't have to keep things that way. You could change the netmask to 255.255.0.0 which would allow addresses anywhere between 192.168.0.0-192.168.255.255 (if you know IP networking, I know that isn't quite true but I'm trying to keep it simple).

Now, most of the devices on your network will use DHCP for which the server is also the router. If you configure DHCP to deliver something like 192.168.1.100-192.168.1.200 with a netmask of 255.255.255.0, the normal devices will only be able to talk on 192.168.1.x

So configure all of your network connected IoT devices manually to use lets say 192.168.2.x also with a netmask of 255.255.255.0 and the traffic is reasonably well isolated. Both subnets can still talk to the router and a decent router would still be capable of controlling the traffic in the different networks (the firewall rules are more complex but then we are only using a single router).

This won't stop a dedicated hack but it will prevent the casual leakage that is the bane of IoT. And it doesn't require lots of hardware.

Note that I wrote that off the top of my head rather than in a test lab so if I've got something wrong I hope someone will (politely!) point it out and I'll correct it.


Why doesn't PCI DSS requirement 4.1 match the SAQ?

Distilling from comments:

The PCI DSS standards document contains the requirements language and also contains testing procedures (column 2) and guidance (column 3) for QSAs and for those preparing for a visit by a QSA. The requirements are numbered in MAJOR.MINOR format and the testing procedures appropriate for a requirement use letters. The testing procedures are not themselves requirements.

The SAQ is a questionnaire for self-assessors. The questions appropriate to a particular PCI DSS requirement also use letters under the MAJOR.MINOR requirement format.

The lettering in these two documents are not intended to line up. Testing procedures and guidance for QSAs are different than questions intended for self-assessment.

If one qualifies to self-assess, then one can use the testing procedures and guidance in the requirements document to deepen one's understanding of the expectations of compliance, but one is only responsible for answering the questions in the SAQ.

If one does not qualify to self-assess them then SAQ should be ignored.


How do Client-specific keys and Certificates work?

If you want to authenticate a client to your server, you will need a private key for each client.

The usual HTTPS method (TLS) uses only one certificate to authenticate a server. The server has his public key published and signed by some authority, the client verifies the certificate and the authority signature of the certificate, then the client is sure to communicate with the right server, since only this server can sign the communication with his own (corresponding) private key.

Usual HTTPS method only authenticate the server.

If you want the client to be authenticated as well, they need their own private/public key-pair. After having authenticated the server, the client will send their public key and the server can then check the certificate against a local database, or a more global infrastructure if the certificates (of the clients) are signed by an authority.

Other parts of the HTTPS protocol support client authentication in this way.


The BTK killer was caught by a similar method, although that was a floppy disk.  The exact means are available in this article.  Additionally, I know of computer forensics that have been used in catching theft of intellectual property when people have switched companies.  In those cases, files from the source company where copied to a USB drive and then taken home.

I don't think it's an easy thing to do, but it certainly is possible.  To be certain, the person doing the forensics would need access to your computer.  I'd wager you wouldn't do that willingly, so that would involve a search warrant.


mail.ru and slightsearch.ru hijacking browser default search engine set by admin

Ok so I eventually fixed the problem.

I had to delete files under c:\Windows\System32\GroupPolicyUsers

Checked all the files contained in GroupPolicyUsers and then deleted those that related to chrome and that was messing with my Registry.

Restarted chrome and now all is fixed!


To answer a bit more explicitly:

  Do I need to use captcha if I am using AntiForgeryToken in an MVC
  application.

If automated submissions are a problem then yes.

  Does AntiForgeryToken prevents automated form submission?

No. A CSRF token basically ensures that a user visits a page (eg. the one which contains the form) before another action takes place (eg. that form was submitted). A bot could easily obtain a valid token to submit a form.

  Can I use AntiForgeryToken as an alternative to captcha?

No. Arguably a CAPTCHA might be able to replace a CSRF token but a CAPTCHA probably isn't practical on every form which needs CSRF protection (eg. one in an admin panel).


What you are describing sounds a lot like how I share PGP keys with my friends. It works fine when we're all nerds and adding keys manually and are chatting on the phone while we do it, but this approach doesn't scale very well.

CAs solve your second bullet in cases where you need to trust the connection the first time, in an automated way - which turns out to be absolutely essential more often than you might think. This is generally referred to as the bootstrapping problem - or "...but how do we do it the first time?"

Scenario 1: I'm at a friend's house and want to check my gmail. My friend uses hotmail and so her computer has no prior trust with gmail.com. How do I know it's the real gmail.com and not a phishing site made to look like gmail.com? How do I "build trust" enough to give it my user name and password? CAs solve this problem because the CA's cert is pinned in the browser, and the site presents a certificate signed by a CA, now the browser trusts that this is the real gmail.com.

Scenario 2: consider a CA in the context of a corporate VPN. The company hires a new person who will work remotely from a different country. You want to make sure that the very first time they connect to the corporate network, they can authenticate the server and didn't just give credentials to your corporate network to some hackers. CAs solve this problem because you can embed (or "pin") the CA's cert into the VPN client executable, and have the VPN server present a cert signed by this CA.

Scenario 3: Email. Something goes wrong on my server. I call up some contractors that I've been referred to and they say "Send us the log files for your firewall and we'll figure out what went wrong". I've never met these guys, how do I get their public key? I suppose they could read me the SHA2 hash over the phone for confirmation, but that's a HUGE hassle. CAs solve this problem because (assuming my IT dept has set up Outlook in some complex ways) Outlook will verify their certificate back to a trusted root.

Scenario 4: Bank transfers. I ask my bank to wire money to my friend who uses some small, unknown bank - maybe overseas. You can bet the bank won't just send money off to some server it doesn't trust. You can also bet that with the sheer number of banks on the planet, a bank will not mail out USB sticks to every other bank every time they need to stand up a new server (which may be an automated stand-up in response to a traffic spike). CAs solve this problem. In reality, the banking network SWIFT uses a complex hierarchy of CAs to secure the world's inter-bank transactions.

In addition to the technical scenarios above there's also the usability issue: in the current model, TLS is protecting your data and your connections whether or not you know it's there, which is great news for my grandmother. Being able to verify all certificates back to a trusted root CA is something that's easy for your browser to do behind the scenes. So even if a more manual system of importing / trusting keys worked, even I would find it unusably inconvenient, and I'm part of the 1% who does this for a living. My grandmother would...well, be in trouble.


Hash a secret API key with a random salt instead of sending sending it alone in REST API

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary credentials is better than constraining permanent credentials.

In sum:

Is this a known technique?

Yes, there are many ways to constrain a token for use in a specific circumstance. Can add the email address as another header and hash the secret/email pair. See also JWTs. Many, many permutations to achieve similar ends.

Is this a decent security improvement?

It is better to use a token with fewer capabilities than one with more, so, it represents an improvement, but as below, there are much better improvements, so while it is an improvement, it's not a decent improvement.

Any downsides?

The permanent nature of the tokens is undesirable. Someone who gets one user's token can presumably get other user tokens, and since they are based on permanent attributes- a permanent secret and the user email- they can be used by the attacker forever. Better to move in the direction of adopting time-limited tokens, which can also be constrained to permit only specific functions.


Malicious tracking script being served from google server to circumvent block lists

Firstly, you should establish whether it actually is malicious (or can be exploited maliciously by third parties).

Google has a dedicated page for reporting bugs, vulnerabilities, fraud and malware. There is more information on Google's security philosophy page.

I don't see a reason why you shouldn't inform them of this. However, before you do so, you should double check that it is not just an issue with your computer (i.e. local malware injecting content into your browser pages) and that it is reproducible.


Are there technical framework for IT sec audit just like there are management frameworks?

Yes, ISO/IEC 27007 provides guidance on managing an information security management system (ISMS) audit program, on conducting audits, and on the competence of ISMS auditors, in addition to the guidance contained in ISO 19011:2011.

ISO/IEC 27007 is applicable to those needing to understand or conduct internal or external audits of an ISMS or to manage an ISMS audit program.

See the index here and the complete content of 19011:2011 here.


How safely allow users to run arbitrary JVM code on a server?

There are Docker containers for Java and I think some of the newer CI services might use those.  You can put all sorts of additional restrictions on those, such as limiting memory/network/CPU/etc.  VMs can also do this of course.


Penetration testing and report submission should be done by a certified CEH or CISSP

There are so many different certifications, that global regulations cannot require one specific one.

Also, certifications vary widely in what they cover. CISSP does not prepare someone for penetration testing. CEH can be seen as too 'light'. The organisation that offers the CEH has a separate certification for penetration testers (LPT).

In the UK, there is CREST for pentesters, which is required for UK companies in some regulatory situations.

At the moment, for standards such as ISO 27001 and PCI-DSS, one just has to prove that the tester was 'qualified' to perform the test.

But never just do something because a regulation said so. They are not supposed to be "check the box" exercises where you do the bare minimum. They are a guide to help you do what's best for the business. The goal is to implement the best form of the regulatory requirement in a way that meets the business goals.


The answer is bit of yes and no, but in some cases, it is a definite no.  It really depends on what security software you are using, and what type of virtualization software you are using.
A traditional antivirus program that just scans a host computer cannot protect your VM.  The reason being as @schroeder said, "An AV on the host cannot access the memory or filesystem in a VM."
If you are using an internet security software that has a HIPS (Host Intrusion Prevention System) feature that acts like a network firewall, the answer is bit of yes and no.  The yes part is if the VM program tries to send a request (considering that you are using a browser inside a VM, like VirtualBox), thru the host to access a website.  In the scenario that the HIPS detects the destination of the request or source address of the data received listed in a global or local blacklist, the HIPS would drop the data.  In that case, the VM would not receive anything.  The no part is related to the fact that the security software would not be able to access the memory or the filesystem of the VM to scan for viruses.


Priming an IDS/IPS for an impending attack

Most IDS/IPS allow you to write your own rules , for example snort rules. So if you have indicators from a 3rd party then adding them in as custom rules is one option.


Is fileless malware is a new type of attack or the media just bringing them now more to our attention to promote sales of related "new" solutions?

Fileless malware has been around for years. It is nothing new. Any malware that runs in memory is considered "fileless".

The common media also has the misconception of thinking that a malware running from the Registry is fileless. Since the Registry is written to the disk inside Registry hives, it isn't really fileless. Same thing for malware that uses WMI.

Real fileless malware is malware that simply lives in a process, in the memory of an hijacked process (since if it was launched from its own image, it wouldn't be fileless, as it would have a trace on the disk). You can think of it as a malware doing process injection, and then deleting itself from the disk, only staying alive within the process that hosts it. As an example, executing a malicious script via PowerShell can be considered fileless.

As for detection, security products have also been able to detect fileless malware for a while now. Powerliks, GootKit and Kovter are examples of fileless malware, according to media's description of the concept.


How to set up a beef hook on another VM's browser in a NAT Network in VirtualBox

I usually when doing hackingtesting between two virtual machines set up two adapters on each one. First on each one as "NAT". That interface will provide internet access through my host (but you must know that NAT network will be different network for each vm). The second one will be as "NAT Network" and that will be the network that the virtual machines will share.

To setup this secondary network interface you'll need to set up first the range of NatNetwork on your Virtualbox. Click on "File", "Preferences", "Network". Click on the "plus" symbol to create one. It will be set as "NatNetwork". Then click on the gear icon to configure it. You can check my screenshot (sorry, the screenshot is in spanish):

Then configuring it you can set up any network range. I put in this case 12.0.0.0/24 in order to have a non-conflicting range.

After that, you must set up the secondary network interface on each virtual machine. Click on the vm, settings, network and enabled the secondary network interface selecting "Nat Network" and your created network.

If you do this on both machines, the machines will have a secondary network interface on 12.0.0.0/24 network and they will see the other machine flawlessly on that network. They will get an ip by DHCP and you'll be able to perform any hacking test.

Of course there are more ways to do that stuff but this one is easy and working. Good luck.


Secure messaging of this nature is indeed a real thing used legitimately. However, criminals know this and may well try to imitate a real secure message to lure their target(s) into opening unsafe attachments.

If you have verified the sender's address, then you are probably safe. But if you would prefer to take a cautious approach you could open the HTML file in a text editor such as Notepad. You can then read the HTML source code and view any scripts/links embedded within it without actually executing anything.

With regard to browser sandboxing, that point is accurate as far as I know. Regardless, there are ways a capable attacker can escape a browser sandbox (although publicly disclosed methods are quickly patched to prevent exploitation).


Why is CertificateVerify message necessary? (Why isn't client authentication done through the KeyExchange)

Your idea doesn't work. Being able to signing the key material doesn't prove that the client has the private key corresponding to the certificate.

Authentication is usually done by a challenge-response protocol in which one party presents a question and the other party provides a valid answer to prove that it knows the rule of transforming questions to answers. The key material (here acts as the question) in the ClientKeyExchange is determined solely by the client while the server doesn't have any control over it. So it's just like making the client answer its own question. Without knowing the "rule" (the private key), the client can still provide a valid answer (signed key material). For example, an attacker can take the certificate and the signed key material from another client and later impersonate that client when communicating with the server. To get the certificate and signed key material from the victim, the attacker can establish his own server and make somebody connect to him.

Actually, the signed hash in the CertificateVerify message includes information from both the client and the server (i.e. the "question" is determined by both sides). So the client is not answering its own question.
Client authentication is optional in an SSL/TLS transaction. Considering clarity and ease of implementation, it's not a good idea to have a message with two forms.

The CertificateVerify message is not strictly necessary. It is OK to merge it into the ClientKeyExchange as long as the materials to sign are carefully chosen. However, it is better to have a separate message since it plays an independent role. By the way, a separate message doesn't necessarily cost an additional TCP segment. It's very common to embed multiple messages in one segment so a separate message won't introduce extra costs.


If Java is inherently vulnerable to System.getProperty injection attacks, is it worth it to validate?

Ensuring it matches a predefined pattern negates the point of having it.

From the oracle documentation -

  Security consideration: Access to system properties can be restricted by the Security Manager.

And also

  The setProperties method changes the set of system properties for the current running application. These changes are not persistent. That is, changing the system properties within an application will not affect future invocations of the Java interpreter for this or any other application. The runtime system re-initializes the system properties each time its starts up. The setProperties method changes the set of system properties for the current running application. These changes are not persistent. That is, changing the system properties within an application will not affect future invocations of the Java interpreter for this or any other application. The runtime system re-initializes the system properties each time its starts up.

So to be a risk you have to expect a malicious party to somehow inject a setProperties call into your running application. Unless you pass user input to a "setProperties" call (which is a terrible idea in general) this should not be a problem. If they can inject code then you have far bigger issues. If you are still concerned then use the SecurityManager.


decrypted signature using CA public key equal to hash of certificate?

The thumbprint is calculated over the entire certificate (TBS and signature), while the signature of a certificate is created against the TBSCertificate structure which is a part of the X.509 certificate.

Ref: RFC5280.

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  Extensions OPTIONAL
                          -- If present, version MUST be v3 --  }

So you need to compare the hash embedded in the signature with the hash of the TBSCertificate portion.


Most firewall policies focus on restricting inbound traffic; they don't try to limit outbound traffic.  That's why this is only applied to INPUT, not OUTPUT.  There would be no point applying it to OUTPUT, if everything that goes out is allowed.

FORWARD is not relevant for endpoints.  It is only relevant for a router that is forwarding traffic.  Most firewall rulesets I see on the Internet are focused on a firewall for an end-user machine or server.


How to Leak Addresses with Format String Exploits

@LiveOverflow helped me figuring out what I couldn't get. Both the assumptions I had were true

printf simply prints what ever isn't a '%' and treats in a special way charcters following '%'
Formatters (%x, %s, '%n, etc...) ONLY use addresses found on the stack (what I mean is that if we start popping off values using %x, those values will be popped of on the stack as long as valid addresses are available

Now in the code in the question, supplying an address as first argument is not enough, we have to somehow put on the stack the address we want to read/write from/to

example:

vuln.c (gcc -g vuln.c -m32 -o vuln):

#include <stdio.h>

int main (int argc, char ** argv) {

    buffer[32];

    fgets (buffer, sizeof(buffer), stdin);

    printf (buffer);

    return 0;
}

We can do by calling the program with an argument ./vuln AAAA. When asked for input we can insert there our format string. Here's the catch: we have to pop values off until we find our AAAA, after %s would dereference the address AAAA and read a string from there aka leaking an arbitrary address. Writing to an address works in the same exact way.

For the sake of simplicity I compiled it with -g so that I could use the *argv symbol

pwndbg> x/4s *argv
0xffffd258: "/home/ncrntn/vu"...
0xffffd267: "ln"
0xffffd26a: "AAAA"
0xffffd26f: "XDG_CONFIG_DIRS"...

At this point we know where to look at

pwndbg> x/200wx $esp
. . .
0xffffd260: 0x6e746e72  0x6c75762f  0x4141006e  0x58004141
. . .

And we indeed found our AAAA (in hex \x41\x41\x41\x41)


Google Analytics showing page views from pages I don't have on my server?

If you display a generic 404 page for those URLs, then Google Analytics may count it as a "page".

With those pages, someone may be attempting to see if you're a proxy, or if your site can be used to redirect users. It's noise traffic that comes from scripts and bots. Unless you have a vulnerability on your site, it's really nothing to worry about.