What are safe solutions to protecting important credentials in source code

There are 2 obvious problems with credentials being stored in the source code are:

The source code can be easily reverse engineered and the credentials extracted.
If the credentials are leaked, you would have to change the password on the server, change the password in the code, rebuild and re-deploy

So one option to get round both of these issues is not to have the credentials in the source code at all.  A suitably protected configuration file may be all you need, read in the credentials when needed, use them and then clear out the memory after use.


Why are cross-domain POST requests allowed?

It seems like giving untrusted parties unfettered write access to your server is a bad idea.

I guess that would be true unless your entire business model depended on it:

https://disqus.com [comment on this]
http://Facebook.com [like this]
https://twitter.com [tweet this]
https://ads.google.com [support this]


OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version

That is a common OpenSSL response when the TCP stream below the handshake is broken.  You say you are pentesting at the moment this happens, this has network security connotations but not the ones one would probably guess at first.  This answer is an educated guess based on seeing that error several times.

When your session is asleep it does not send keepalive packets (i.e. does not send extra ACKs).  Such a "dead" TCP session will be cut off by a stateful firewall, no matter if the firewall considers the connection valid (or harmless) or not.  Since you are pentesting I would imagine you are working within a network where several firewalls are in place.

Why would a stateful firewall do this?

Today, stateless firewalls are pretty much history* therefore all firewalls are stateful, they keep the state (and history) for each connection that goes through the firewall.  They perform this not only for NATs but for any traffic passing through the firewall.  Such a stateful firewall is vulnerable to a DoS attack by leaving too many hanging connections and filling its memory.  To prevent that a stateful firewall have a timeout upon which it drops the hanging (no traffic during the timeout) connection.

When you wake up your SSL session, it sends an ACK.  But the firewall had long dropped that connection from its memory and is clueless about the existence of the TCP session, therefore it answers with RST.  The RST provokes a state=unknown error from the SSL level.

The system at the other side of the firewall may well be aware of your connection, and would answer had the ACK reached it.  But the firewall will not let that pass.

What can you do about it?

Not much.  You could run a stateful proxy on your own machine which would keep sending TCP keepalive on one side (the outside), but would not require keepalives on the other side (the inside, loopback).

Yet if you, for example, put your entire machine to sleep, then the stateful proxy will not send extra ACKs anyway defeating it purpose (and it will make connection debugging even harder that it already is with just the firewalls).

* A stateless firewall is vulnerable to trivial attacks (bypasses), such as IP fragmentation of the initial SYN packet.


How to block all porn websites from firewall?

Your best bet may be to head over to OpenDNS.com and setup your network interfaces to block sites by category according to your preferences. You simply replace your current DNS ips with 208.67.220.220 and 208.67.222.222. It's a free, maintenance free solution that additionally offers some protection against the DNS attacks that we are seeing frequently today.

Also, since you are adding these IP addresses for your network interfaces, i.e., ethernet, wireless, it will work across browsers. You can even configure the block page the user sees. There are also other options including Comodo.com. Good luck.


Why is using the chip in chip-cards required at manned points of sale?

Swipe cards aren't secure, even under human supervision.

It takes only seconds to swipe a card and read all the data off the magnetic strip.  Once you have that data, it's possible to write it to a new blank card.  The card can be printed up to match a real bank's credit cards.  The fraudster can now sign the back of the new card.

To the cashier, it will look just like a genuine card.  It will swipe correctly, and the signature on the back will match the one given by the person using it.


If you fix this issue, I believe you will be successful.

gef➤  ropper --search pop
[...]
0x0804901e: pop ebx; ret;
0x080491c4: pop edi; pop ebp; ret;
[...]

These gadgets don't "mess up" the stack in this case; they clean it up a bit after the overflow so that you are able to return to the next function in the chain. The gadget you picked instead is close, but would need to be an add esp, 4 instead of 8, or without the additional pop. You'll see why if you step through it in the debugger.

So, instead use the pop; pop; ret from above.


Are Kismet (on OpenWRT) and Snort IDS (on a linux server) compatitble?

I think libpcap and/or tcpdump are what you're looking for. Kismet is a wireless analyzer that will display the 802.11 metadata. There was some activity awhile ago to add 802.11 intrusion detection capabilities (snort-wireless). You might still find useful remnanats of that.

Kismet pulls the 802.11 frame data and analyzes that, then examines some of the TCP/IP data (when it's unencrypted or decrypted) for additional network activity reporting. Kismet can also log the captured data, which you could then feed into an IDS (or any other process) using tcpreplay.


Malware threats from other mounted hard drives

Malware can only be executed if something loads it and executes it. Malware in the form of a Windows program will not run unless you boot Windows or you run a Windows emulation layer on Linux. In the latter case, it's unlikely (but by no means impossible) that the malware will have enough privileges to do harm.

It is however possible for malware to come with Windows but run outside of it, Windows being here the platform of the malware installer but not the platform of the malware itself. The malware could lodge itself in your hard drive's boot sector or could even infect your BIOS or other firmware.

It's also possible for malware running under Windows to access your Linux drive (unless it isn't physically plugged in) and plant Linux malware there.

These threats are not very common. Linux compatibility is not a feature that most malware authors aim for, and there isn't much hardware-infecting malware in the wild. In practice, such malware is unlikely to arise in the form of an untargeted attack. Targeted attacks are a different matter; if you're concerned about the NSA spying on you, get new hardware (among other precautions).


Vulnerability in using `input type="text"` for website password other than shoulder surfing

Beyond shoulder surfing the browser can insecurely cache data. It may save input fields in an insecure manner, for auto-fill purposes. This means passwords may be tab completed, easily retrieved as plain text, and copy/pasted.


Can Android spyware like Pegasus survive flashing of a new ROM?

As long as your blootloader is unlocked, a spyware that has gained privilege escalation on your device can keep itself persistent across custom ROMs. Custom ROMs only flash /system and /boot partition. Some custom ROMs also flash /vendor partition. Other partitons like /radio, /misc, /persist and ODM partitons remain untouched by aftermarket development.
In locked bootloader, if vulnerabilities are not in Android Verified Boot (AVB) and SoC's secure boot, tampering with system and bootloader will brick the device on next reboot. To prevent the device from getting bricked, spyware apps gain temporary root after each reboot and these ones can be removed by factory reset of device or just by uninstalling the identified spyware.
Custom ROMs can deliver security updates for android framework only. OEMs also deliver security updates for underlying Linux kernel, drivers & firmwares, bootloader and Trusted Execution Environment (TEE). Known vulnerabilities in vendor components cannot be patched if OEM has dropped support for your device. Don't use custom ROMs that don't enforce SELinux.  There is already an exploit to gain root in SELinux permissive mode | Explanation. SELinux permissive doesn't block processes for violating SELinux policies. It only reports them.
Another option is to use custom AVB which is only supported by Pixel and OnePlus. Custom AVB allows relocking of bootloader but with custom root of trust. This will ensure integrity protection of your custom ROM while also receiving security updates for android framework.


Are credit-card security codes theoretically insecure (if not entirely broken) already?

Deriving the issuer's encryption key using a collection of credit-card numbers with their respective security codes would be an example of a known-plaintext attack (KPA).

To be considered secure, a cipher has to be resistant to known-plaintext attacks, i.e. cracking the encryption even with a large number of plaintext-ciphertext pairs should not be significantly quicker than brute-forcing it. This is a basic requirement for ciphers to even be considered for practical application.

In cipher design and evaluation, it's assumed that the attacker has as many known plaintext-ciphertext pairs as he wants, and can produce new ones by feeding chosen plaintexts to be encrypted (CPA). In IT security, known plaintexts are a given - for instance, this page is being served to you encrypted through HTTPS, but any attacker can get most of its plaintext by visiting the website. If this allowed them to derive the private key, HTTPS would've been rendered pointless.

Modern ciphers such as AES and even most deprecated ones are KPA resistant if used correctly. The only use plaintext-ciphertext pairs would have is to check if your key matches.

Outdated, pre-computer era ciphers weren't secure and could indeed be broken with KPA; that's what happened to the Enigma. It's also possible to break modern ciphers with KPA/CPA if they're used incorrectly, e.g. with repeated IVs and nonces. Bad usage can reduce any cipher's security to a simple XOR, so a secure scheme takes more than just a good cipher. Whether any banks have screwed it up quite that badly... I hope not.


Mongo DB hacked (read_me_to_recover) without the port exposed in the firewall?

Exposing a port through Docker bypasses ufw because Docker directly creates an iptables rule.  So your firewall is useless.
You do not actually need to expose the container port to the host, however, in order to enable other containers to access it.  I recommend simply not exposing your ports  except if they need to be accessed externally.


How can application like Whatsdog detect user online status from Whatsapp?

It's actually by an undocumented API from whatsapp and you can communicate over Websockets to get the online status of people.

This article will show you how it is done and even provide a PoC for it to run in your own browser. So this PoC can be modified to be a PC application or a smartphone app.


What prevents recorded voice samples being used for authentication on other systems?

Nothing, except loss of fidelity due to the recording and playing back, provided the system is amenable to a replay attack.

But if you do acquisition and playing back at a higher fidelity than the voice recognition system was built for, the latter won't have a clue.

It might be possible to analyze echoes and harmonics: a human phonatory system does not produce sounds from a single point in space, while a loudspeaker does. This would require several sensitive microphones placed in different positions, to be able to calculate time-of-flight for different phonemes.

Challenge/Response

Another possibility is if the attacker has only access to a fixed recording and we can also do voice recognition.

I think I saw this in some 007 film, with the guy approaching a voice-activated door and fiddling with his watch, from which the 'Nice party. I recommend you the shrimp salad...' captured the evening before in the villain's voice issues forth, unlocking the door.

But what if the door had asked, 'Repeat after me: horse battery staple correct'? The shrimp salad wouldn't have cut it.

So:

the voice is enrolled
the user is asked to pronounce a certain sequence, different every time
the sequence and the voiceprint must match.

This reduces the chances of a replay attack because even if someone recorded my voice saying '577892', they wouldn't be able to pronounce in my voice '297779'. Or would they? With a large enough sample and voice synthesis technology similar to Loquendo TTS, it is possible to have a computer say anything in my voice. With only a few words or digits, the attacker doesn't even need that much technology.

The need to avoid both false negatives and false positives, added to the background noise, requires threading a very difficult needle: you could reject exactly identical phonemes as being recordings, but background noise (either real or faked) would make this very hard - two playbacks of the same sound would be acquired as different, while the same person's voice will naturally generate almost identical phonemes.

Over a telephone, any attempt to distinguish between "real" and "artificial" phonation will fail, because the phonation will always be artificially flattened by the sender's microphone.

I am in no way an expert in artificial voice fakery, but I'm quite confident that a very reasonable budget to acquire voice samples, recording equipment and a voicesynth framework will allow you to bypass any such voice-authentication over the phone. Against an unprepared opponent armed with just a tape-recorder, voiceprint plus challenge/handshake will probably always win.


Securing traffic between devices on same local network

Whether you should or not isn't really an opinion we can offer: yes you should (or maybe it is). What you really need to do is figure out what risks are present in the interactions between applications.

If the network itself is compromised, that doesn't mean the applications or the users are compromised. It just means an attacker can see traffic over the wires. Encrypting that traffic mitigates any privacy-related problems, but it introduces a few subtler problems like how do you exchange encryption keys, how do you verify the keys if you're using PKI, etc.

That said, if you mean the network as many or all computers on the network are pwned, well, that's a different problem. Encryption might still help, but the problem moves in to the realm of protecting the keys.

So you need to ask yourself: what am I needing to protect against? What am I willing to protect against?


SSL handshake exception: unable to find valid certification path to requested target

The trust chain for this site is like this:

[0] /CN=www.vitalityinstitute.co.za
[1] /CN=Entrust Certification Authority - L1K
[2] /CN=Entrust Root Certification Authority - G2
[R] /OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority

The first 3 certificates are send by your server and the last one should be in the local certificate store as a trusted certificate. But, according to this PDF from 2010 this certificate is not included in the trust store by default. Instead older certificates from Entrust are included.

Thus there are probably two options:

add the missing certificate as trusted to Java
or add the missing certificate to the chain of the web server. Since this certificate itself is signed by an older certificate from Entrust and this older certificate is probably included in Javas trust store this might just work. Unfortunately, this might cause problems with OpenSSL based clients as described here.


In Metasploit, how to use a custom exe as payload?

You can execute any payload file or string you like using the msfconsole with these options:

PAYLOADFILE The file to read the payload from
PAYLOADSTR  The string to use as a payload
ARCH        The architecture that is being targeted
PLATFORM    The platform that is being targeted
VERBOSE     Enable detailed status messages
WORKSPACE   Specify the workspace for this module

http://www.metasploit.com/modules/payload/generic/custom


Why is privacy not one of the pillars of information security?

Confidentiality is generally a privacy concern. It's just a more general term.

It's like saying animal instead of dog.

In addition to the definitions, you can confirm that by searching for synonyms of privacy and synonyms of confidentiality. You can use confidentiality instead of privacy, but not the opposite.


Requiring regular password change counterproductive

There was a healthy debate a couple of years back here, I hope it's stickied.  Lets see:  How does changing your password every 90 days increase security? was where we had this.

The NIST itself gathers feedback from industry, government agencies (most specifically: the intelligence community) and provides guidelines to government as to how to secure their systems against nations stealing them.  I realize that's an appeal to authority and not a reference, but hopefully it helps provide context for the NIST.


is it worth to implement a firewall on a web server you control?

As you've implied, security is about layers.  Systems get attacked and they get breached in a myriad of ways.  By layering our security solutions, we prevent our systems from being subject to a single point of security failure.  Sometimes people put firewall devices off-box and sometimes they also put them on-box.  Sometimes they do both for just the reason you state: to protect against configuration errors -- a very real, well-defined, and exploitable human condition.

However, from reading your question, it almost sounds like you do not have the infrastructure to support a firewall off-box.  So if it comes down to NOT having a firewall and having a firewall -- albeit on your web server -- then put the firewall on your server. The firewall prevents more than just connections to other services. It can prevent certain types of flooding attacks, it can prevent odd and malicious packets from entering the system, it can protect against operating system weaknesses, it can protect against mapping your network and it can protect against data being exfiltrated from your system.


If I remember correctly, this folder is created by apps than contain ads created by TaoBao. Alvin2 seems to be regenerated, even if you delete it, by the same apps that create .UtConfig.

They have been existing for quite a long time and the .xml doesn't seem to cause any trouble


TOTP is an HMAC.  It just happens to be an HMAC of a timestamp with some granularity where the passwords need to be rotated.  Note that with either a time-based HMAC or some other HMAC, an attacker with a copy of a legitimate client can extract the shared key and use that key to forge requests from their client.


Why is NIST removing & not updating TLS guidance? What is the replacement?

It took nearly a year, but NIST has released this bulletin explaining the update and also providing the updated document for SP 800-52 Revision 1.

The answer to your question is expressed in the bulletin:

  NIST published the original version of SP 800-52 in 2005, but withdrew
  it in March 2013 because the guideline had not yet been updated based
  on the new versions of TLS and known vulnerabilities. This new
  publication is the final version of SP 800-52 Rev. 1, which
  incorporates public comments to the draft version made in the fall of
  2013.

  Chief among the changes in SP 800-52 are the recommendations that
  government servers and clients move to TLS 1.1 and 1.2. It also
  recommends that they adopt cipher suites with NIST-approved algorithms
  to support 112-bit security strength and higher.


How secure is iterative password enhancement?

To a first approximation, your problem is one of entropy computation. Estimate the entropy of your first password then the entropy of your second one and compare the two. You should aim to have at least 128 bits of entropy. Zxcvbn is a good estimator. You can also do it by hand.

Compared to inventing a new one, do what's more convenient for you. However, if you reused this password in part or in totality elsewhere, you should definitively invent a new one for your password manager.


Security benefits of disabling Chrome Incognito mode?

Incognito mode (if not properly configured) can disable some extensions, if your company is disabling it via some sort of GAPPS mgmt or via GPO then they should be able to force the settings to force the extensions to run.

Besides, the simple answer of it might break something and they just chose to disable it instead of answering questions, i couldn't tell you why, especially if they allow inprivate on edge


Are CVE counts a good indicator of a software's security?

Can we say that a software is "more secure" than another, based on the number of CVEs these softwares have?

No. CVE entries are not a good source to rank products by their "overall security".

The main idea behind the CVE system is to create unique identifiers for software vulnerabilities. It's not designed to be a complete and verified database of all known vulnerabilities in any product. That is, a vendor or researcher could simply decide to not request a CVE number for a given flaw. Further, entries sometimes combine related bugs under a single ID or don't disclose the exact impact, making a simple "bug count" a rather meaningless security criterion. Also, for a ranking you'd have to find sensible metrics to compare different severities. (How many DoS bugs equal a remote code execution...?)

That said, CVEs do surely give you an idea about what kind of vulnerabilities have been found in a product and they're a good starting point for research. But the amount strongly depends on the age of the software and how much attention it receives through security auditing. You can't really reason if a lot of CVE assignments means that the software is poorly written or if it actually means that it's particularly secure because evidently a lot of vulnerabilities are getting fixed. I personally tend to find it suspicious if an older product has a very short record of patched vulnerabilities because that could indicate it hasn't been audited thoroughly.

So you should think of CVE as a dictionary rather than a database that simply assigns handles to vulnerabilities so that you can reference them easier — don't use it as a tool to compare security.

Here are some better indicators for a secure product:

The software is used and developed actively.
The vendor encourages people to search for vulnerabilities (and maybe even offers bounties).
New security bugs are processed and patched quickly.


Is there any security reason to prefer local IP address over zeroconf ".local" domain name?

SSH stores host keys. If the host key is not matching what is expected for a given name or IP, you will at the very least get a warning with all SSH implementations I've tried. OpenSSH will by default reject the connection, and you will have to manually run a command to remove the offending key.

VNC does not have this protection, but you can wrap it inside SSH to achieve same protection as SSH offers against MiTM.


Attack vectors when running untrusted docker images

There's various ways that a rogue container might be able to damage the host or other containers on the network, depending on the configuration of the docker daemon.

By default all containers share the same network.  As such a rogue container can attempt to attacker other containers.  This could include attacks like ARP poisoning depending on the rights provided to the container.
On the network front, a rogue container has a potentially privileged position in your environment and could try to attack other systems on connected networks.
A rogue container can attempt to escalate privileges to compromise the host operating system.  This is generally achieved by attempting to exploit kernel vulnerabilities in the host kernel.  An important point about container isolation is that all running containers share the same kernel.
On that note, if the kernel exposes any sensitive information to the containers (e.g. information from the /proc filesystem) it might be possible for the rogue container to get access to that.
If the container is executed with certain configurations, e.g. --privileged or mapping the docker socket into the container, it becomes trivial for the rogue container to take over the host.

I'd recommend reading the CIS Security benchmark for docker to get some more information and suggestions for hardening your installation, if you're interested.


What is the best way to represent heavy hash decryption for a hacker movie?

To keep real I'd go for john the ripper. Holding any key will result in displaying current status. Also, remember that it's not possible do decrypt a hash since it's a one way function.


what are security precautions to ask clients who send a USB or CD?

The standard procedure is to:

Use only one PC to plug the sticks and read the CDs/DVDs
To have that dedicated PC isolated from the network except one (only one) network share to where the materials are copied
To have all Windows Updates and AV updates

The above will help you:

Avoid USB and DVD Trojans affecting any PC to where you would plug it in
Reliably run AV scan on every new material

The main point is, that you have reliable machine for such operations so you do not risk giving USB sticks and DVDs to random employees where AV may be switched off or not up to date.

And even there might be some advanced USB exploit, you do not risk much as you are isolated from the network (you don't have permission to browse internet except updates and one network share), and when you copy the files, these are AV scanned. The USB stick virus if crafted by hacking company can bypass AV software.

Frankly speaking, this happens sometimes. Depends how much of target you are, so the more you are, the better precautions must be taken.


What does enable-static-engine do in Openssl ./config

From the README, which is the first thing you should read when compiling the software by your own:

 INSTALLATION
 ------------

 See the appropriate file:
        INSTALL         Linux, Unix, Windows, OpenVMS, ...

And, from the INSTALL file one should read according to the README:

  no-static-engine
                   Don't build the statically linked engines. This only
                   has an impact when not built "shared".

To understand what this means I recommend to read the section How do I build a "dynamic" ENGINE? in the README.ENGINE file. It is not trivial to understand, it is probably irrelevant for most users of OpenSSL and it is not about security but about programming, i.e. off-topic here.


What vulnerability do inline javascript and event handlers expose?

If so, isn't this an issue with the fact that a user somehow has the ability to serve whatever they want to users from your site?

It is actually very common that users have the ability to serve their own content. Just have a look at all the social networks and public blog sites where users can provide their own content within a site they don't own.

  How is this a CSP problem?

Usually the content added by users gets sanitized, i.e. script and other things are removed. But, this sanitizing might have bugs. CSP offers an additional line of defense: if CSP disallows inline script no inline script will be executed even though some inline script might have bypassed the sanitizing.


Is it practical to pre-blacklist certain GeoIP regions?

It's essentially a business decision, rather than a security one. The risks from a business perspective are that you lose users from that country, or who are accessing the site from VPNs located in that country, and that, whilst really unlikely, it's theoretically possible for IP assignments to change, meaning that if you didn't keep these blocks maintained and updated with the latest assignments, you might accidentally block legitimate users from target countries, who happen to have been given IPs from a pool previously assigned to a blocked country.

From a security point of view, it can reduce the volume of attacks, and increase the costs to an attacker of targeting your site (since they need to get machines from specific countries, rather than any machines).

It tends to make sense when you have a regionally restricted product - think of shops where goods are only shipped within a specific country, competitions which only accept entries from people in a given region, or systems which work in conjunction with physical businesses which have a limited range (e.g. deliveries to a national chain store, so there would be no way for a user elsewhere to benefit from the service). In those cases, it tends to be easier to justify the risks, since there is no way people from other countries can use the service (and it wouldn't be hard to include neighbouring countries in case of edge cases - a Portuguese business might include Spanish IP ranges, just in case, say).

It makes less sense when you have an information business, or a digital product. In these cases, you might end up getting more unwanted traffic, as people who want to obtain the product resort to VPNs within allowed countries. Think artificial restrictions such as film releases staggered around the world, TV shows with months of delay before being shown outside the country of origin, or game releases.

You can obtain country specific IP lists from sites such as http://www.ipdeny.com/ipblocks/ and then choose whether to use a whitelist approach ("we only deliver to southern Italy, so will only allow Italian and Vatican City IP addresses") or a blacklist approach ("we see lots of attacks from Australia, so will block all Australian IP addresses").

(Please note, all countries are randomly selected and should not be taken as approval or disapproval of given countries.)


Why do browsers disallow script closing an opener window, yet allow changing its location?

Browsers typically don't allow a child tab/window to close its opener with script. And yet they do allow the child to alter the location of the opener tab/window.

This is not entirely accurate. If you read the quoted MDN text more carefully, it is actually referring to the opening of the parent, not the relationship to its popup. The actual restriction you are probably running into is:

Scripts may only close windows were originally opened by script.

So in your specific example, the popup was opened by a script, but the opener was opened by a user, and therefore the opener cannot be closed by either itself or the popup.

Imagine a scenario where there are two popups

User-opened tab (cannot be closed)
Popup 1 (opener is user-opened tab)
Popup 2 (opener is popup 1)

Popup 2 can close popup 1 in this scenario.
However, popup 1 cannot close the user-opened tab because that violates the rule above.

In Chrome & Firefox, it does not matter whether the popups are same origin as their openers. The popup can change the location or close the opener as desired, subject to my first point above.
In IE11, the popup can close the parent, but cannot change parent.location unless it it meets Same Origin policy. (results in new popup if you try)

Also, I'd like to clarify that any opener can close its own popups or change their location without restriction. Access to the popup contents is still subject to Same Origin policy for security reasons.

  This leads to a curious workaround whereby you can create a page that does nothing but close itself with script as soon as its loaded, and then change the location of the parent tab/window to this new page, effectively closing it. ... does this workaround effectively create a back door?

To answer your question directly, there is no such workaround. The linked example will produce the error:

  Scripts may not close windows that were not opened by script.

Unless you are in a 2-popup situation as I explained above, in which case the popup could just close its opener directly. The workaround would be unnecessary in that case though.


Why can't a rainbow table attack identify and trash the salt?

A couple of items to consider:

It is important to note that a rainbow table works differently than a straight-up precomputed hash table. (althought a rainbow table with a chain length of 1 is essentially the same thing as a precomputed hash table -- most rainbow tables have many many chains though)
Rainbow chains have trouble with passwords with LARGE salts.  A short salt (6 chars) might not be a huge problem for them to deal with. (but again, exponentially longer for each additional char)

The problem with straight-up precomputed hash tables is that they get HUGE.  Even generating a precomputed table of only digits, length 0-8 turns in to many gigabytes.  If you start adding in alpha/symbols it gets gigantic.  So the addition of even 6 characters of salt will increase the size of your lookup table greatly.

A rainbow table offers a mix between storing on-disk and computation by using chains. You would use less space than a full precomputed hash table, and it would probably be fine for short salts, but dealing with large salts would require a LOT of space.

Here is an excellent site that describes the actual steps and gives examples for how it works:

https://stichintime.wordpress.com/2009/04/09/rainbow-tables-part-5-chains-and-rainbow-tables/

This other post explains a bit more about rainbow tables:  What are rainbow tables and how are they used?

To summarize -- it is plausible that you could use a rainbow table or a precomputed hash table to solve the passwords. The salts just add more entropy by adding characters to the length. It DOES make it WAY HARDER as you are essentially now brute-forcing a random password of n-chars + salt.

Lastly - to address the issue that if you already know the salt:  I don't believe this would do you any good, as the hashes are one-way and because of how rainbow tables work you would have to have a custom reduction function in the rainbow table that generated plaintexts that ended in the salt. Otherwise since rainbow tables generate their next plaintext off the reduction of the previous chain, if you didn't use a custom reduction function it would be impossible to incorporate the salt to the end of the resulting plaintext. It would probably be simpler to use a plain precomputed hash table in that instance but again you would need one for each salt.


Who to assign read/write access rights for a single-user application to run correctly?

You can either add the individual user or use built-in groups. The simplest way would be to assign the group read/write permissions to the parent directory the application needs permission to and propagate permissions down to the children via inheritance (usually automatic).

As far as groups there are many built-in groups as well as custom groups you can create.  The default local groups, Administrator and User, should be sufficient to accomplish what you want.  Alternatively you can also use the Authenticated Use" group.


Meltdown and Spectre regarding Firewalls and Sandboxing

Meltdown and Spectre are hardware vulnerabilities. They actually reside in your processor and are interested in sensitive information.

Meltdown is specific for Intel Processors.

Spectre is for processors other than Intel (not Intel).

Meltdown bypasses the 'protection mode' that is present when you want to access sensitive data that is stored in your processor.
The attack imitates the role of a normal user that is accessing the
data. The reason sandbox is useless is because the operating system
thinks it is a normal user not an attacker.
It could be possible that firewall will detect the malware. This will require software patches (updating your Operating System version).

In conclusion

Most computer providers have released software patches to overcome these issues. Since these are hardware related, it means that the hardware is what needs to be improved. Software can help, but not fully.

UPDATE

Built-in Firewalls are updated along with the Operating System (OS), since Firewalls are human programmed, they need to know how malware activity behaves. So, if the most recent version of OS is running on you device, the likely hood that your Firewall will know that this malware is carrying out Meltdown or Spectre 'activity' is high. This is because they are now aware of how these vulnerabilities will act.

As for outgoing traffic, and in terms of Iptables, it is unlikely that you know which IP address is trying to access your data.

I would also like to emphasise, again: Software can help, but not fully.

Hope it is clear now.

End of UPDATE

References:

Kocher, Paul, et al. "Spectre Attacks: Exploiting Speculative Execution." arXiv preprint arXiv:1801.01203 (2018).

Meltdown and Spectre. (2018). Meltdownattack.com. Retrieved 1 April 2018, from https://meltdownattack.com/#faq-fix


What is the difference between a jumpbox and a reverse proxy?

"Jumpbox" (along with similar terms such as "jump server", "hop box" and the like) is meant to describe a server that sits between a client or management system and the target server or system being managed, which a user or application logs into from the client, and from there initiates a second session to the target server. There is no implied directionality with respect to whether the client and server each exist within a given network perimeter or outside of it, but generally they will be on opposite sides of such a perimeter and thus unable to directly reach one another using the desired protocol. Typically a command-line-based protocol such as ssh or telnet is used.

"Reverse proxy", on the other hand, is a bit more specific. A "proxy" server is defined with respect to a specific protocol or set of protocols, typically web (HTTP/HTTPS) and/or FTP, and allows the client (browser) within the network perimeter to access resources outside the perimeter by making connection to the proxy and asking the proxy to access the external resource on its behalf. A "reverse proxy", therefore, operates in the opposite direction: the client is outside of the network perimeter and the resources are within.

Many TCP-based network protocols can be relayed in this manner, and it's very much a matter of arbitrary convention which term is used for which set of protocols.


Pen testing is a delicate and potentially fraught undertaking, and not the sort of thing to teach yourself on-the-job.

Beyond just leaving footprints, I'd also be worried about accidentally leaving destruction behind, or accidentally overstepping the limits of your target set.

Rather than being afraid of your peers, you ask them to assist on your first several jobs and observe what your doing; ostensibly so that they can catch things you miss, but primarily to prevent you from doing something stupid. And it helps to have someone to ask questions to.


When is it appropriate to check the from part of a mail address and to not only validate the domain?

The 'when is it appropriate?' question is going to be company dependent. Some very small organisations may wish to authenticate senders, while some very large organisations may not.

It may be better to decide whom within the company should be authenticated. In the classic social engineering attack where by the finance person gets a fake email from the CEO demanding they transfer money to an account or risk getting fired, resulting in them sending money to an attackers account - it would have been appropriate for the CEO to have had their email account authenticated to prove it was them.

It could therefore be a suitable decision to decide to offer ways of authenticating key employees (using SMIME for example) such as the CEO, directors, and finance team. - Any outsourced finance companies would also be wise.

This may offer an acceptable risk level where by you are happy that key people can be authenticated, while the rest of the company are excluded and do not need the resource/training/finance overhead to deploy and manage.


What regulations *require* multi-factor authentication?

This is kind of tangential to the question, but that courthouse is in walking distance for me so I followed the PATCO case closely (and the defense lawyers are across the street from my office).

The magistrate's logic is horrid... and unfortunately a judge accepted that recommendation, so that particular case was decided. However, (US legal theory) this is a district court, not an appeals court. The decision is not a binding precedent in future cases in any part of the country.

I referenced that case earlier when writing up an answer on muti-factor authentication for How is "something you have" typically defined for "two-factor" authentication? If another case were to come up involving similar questions, the logic whether cookies can qualify as "something you have" would be argued anew, though I'm certain at least one side would point to this case.

Assuming there isn't a definition that is relevant to the case (much like the FFIEC didn't define this particular question), a judge would decide how that should be interpreted in the context of a case based upon expert testimony.

With the above considered, I don't know of any legal standard, ruling, or precedent in law that defines the boundaries of what different systems qualify as which factors of authentication.


Is it safe to leave MySQL root user without a password if it uses auth_socket?

MySQL socket authentication is a bit different from conventional authentication. Instead of requiring you to type in a password, it simply checks who you are on the system. From the MySQL developer docs:

  As of MySQL 5.5.10, a server-side auth_socket authentication plugin is
  available that authenticates clients that connect from the local host
  through the Unix socket file. The plugin uses the SO_PEERCRED socket
  option to obtain information about the user running the client
  program.

  ...

  The socket plugin checks whether the socket user name
  (the operating system user name) matches the MySQL user name specified
  by the client program to the server, and permits the connection only
  if the names match.

  Suppose that a MySQL account is created for an operating system user
  named valerie who is to be authenticated by the auth_socket plugin for
  connections from the local host through the socket file:

CREATE USER 'valerie'@'localhost' IDENTIFIED WITH auth_socket;

  If a user on the
  local host with a login name of stefanie invokes mysql with the option
  --user=valerie to connect through the socket file, the server uses auth_socket to authenticate the client. The plugin determines that the
  --user option value (valerie) differs from the client user's name (stephanie) and refuses the connection. If a user named valerie tries
  the same thing, the plugin finds that the user name and the MySQL user
  name are both valerie and permits the connection. However, the plugin
  refuses the connection even for valerie if the connection is made
  using a different protocol, such as TCP/IP.

To summarize, this protocol assumes that a user who is already logged in to the system should be allowed to log in to the database as that user (assuming that user exists in the database). So, it relies on you having secured the server such that users who are accessing the database should already be trusted.

It also doesn't affect your remote attack surface, as the socket authentication can only be used locally.

TL;DR: as usual, your database's root account will be only as secure as the root account on the system.


OTP vs. U2F for online banking and email (vs. store key on USB)

Standard password (even locally encrypted), xOTP (OTP, HOTP, TOTP) [with or without SMS codes] have many vulnerabilities and the most important now is : NO REAL PROTECTION AGAINST PHISHING. A quick visual reminder about that : http://www.neowave.fr/pleaseno/SMS_OTP_TOTP_QRCODE_SSL_ARE_NOT_SOLUTIONS.pdf

FIDO U2F is a true but simple PKI based solution (Elliptic curve / assymmetric cryptography), even if not perfect, no easy relay / phishing attack will work on FIDO U2F.

Regarding Xiong Chiamiox comment : FIDO U2F already exists for desktop/laptop (Windows, Linux, OSX) as USB Security keys but there are FIDO U2F NFC Cards available too for Android smartphones and tablets. Later this year, there will even be Bluetooth Low Energy (BLE) device that will -at laaaast- bring FIDO U2F to iOS device.


Is redirecting in htaccess providing enough security for sensitive pages?

This can provide adequate security, if configured correctly.

I can think of one common flaw: with Apache and rewrite rules, it is often possible to construct an URL that points to the same file and is not redirected. For example, requesting /Config/config.php redirects, but requesting //Config//config.php does not. This is because the rewrite rule matches an exact URL, not any variation.

Another common error when using redirecting for security is sending the header to redirect, but not preventing the page to render. An attacker can then access the pages by removing the Location header. However, this is typically an error in the application and not when using Apache to do the redirection.

A better way is to place the config file outside of the web root. So you have index.php in a subdirectory public, and config.php outside of this directory. This reduces the possibility that you expose the configuration.


Encryption Key Storage and floating point encryption

Encryption works on sequences of bits. It can encrypt anything that can be represented as bits. It cannot encrypt anything that has not been converted to bits. Fortunately, anything in a computer, by definition, is, at some level, a sequence of bits.

Conversion of floating-point integers into bits and back is a common thing to do, subject to some standards such as IEEE 754. Some programming languages already offer functions for doing such conversion in a deterministic, well-defined way that maximizes interoperability; e.g. in Java.

As for key management... the most important point to understand is that encryption is not some kind of magic security sauce that improves security simply by being applied more or less generously. Encryption does not create confidentiality; it concentrates it. Suppose you have some (possibly big) chunk of data D, that you want to keep confidential even against people who can peek at the data where it is stored. By encrypting D (if it is done properly) with a key K, you have reduced the confidentiality issue to that of K: if attackers cannot see K, then they won't be able to see D even if they see the encrypted version of D. But you still have to think about how to keep K out of reach of these attackers.

For instance, if your attackers can take a dump of your database, full of data which was encrypted with K, and K is also stored in the database, then encryption was totally useless. Encryption can make sense only insofar as the key can be kept out of reach of attackers through some other methods (of course, the key being small and not changing often, it makes that task easier). Otherwise, encrypting all the data becomes, in fact, some elaborate dance that will spend CPU cycles, increase development costs and appease auditors, without actually making things more secure.

Encryption is a tool, not a goal. You don't encrypt because you want to encrypt (well, unfortunately, encryption is often applied for that exact reason). You encrypt because, within a given security model, you have determined that there is a confidentiality issue for data that is stored or transferred, and encryption can help in reducing that risk by mathematically moving out large chunks of hardware and software out of the exposure window. The model and the system architecture will tell you who (in terms of both people and system components) is supposed to access the data, and who should not; in other words, where the encryption/decryption key will have to be known; this, in turn, implies what kind of key management you need (number of keys, lifecycle of keys...).


Is this url verification with startsWith secure?

Such check is safe.

A similar check might be error prone. For instance, if you used

url.startsWith("https://www.example.com")

it could give an unexpected result, if you had a URL like

https://www.example.com@www.google.com

The part before @ would be interpreted as a user+password. But it user+password cannot contain unescaped /. The URL you test includes / (...com/...), thus your against such attacks.

I don't see any weaknesses in your check.


Yara condition count operator with wildcard

Your rule condition will match if at least 3 of the string found, not the count of all the string found. Because Yara doesn't mix the wildcard identifier(*) with counts(#), you can only use regex to simplified the count.

rule countstr
{
    strings:
        $a1 = /(string1|string2|string3|string4|string5|string6|string7|string8)/
    condition:
        #a1 > 3 and #a1 < 10
}

Bear in mind that regex cannot compete with plain string matching. For performance concern, you need to resort to something like the following.

rule countstr2
{
    strings:
        $a1 = "string1"
        $a2 = "string2"
        $a3 = "string3"
        $a4 = "string4"
        $a5 = "string5"
        $a6 = "string6"
        $a7 = "string7"
        $a8 = "string8"
    condition:
        (#a1+#a2+#a3+#a4+#a5+#a6+#a7+#a8) > 3 and (#a1+#a2+#a3+#a4+#a5+#a6+#a7+#a8) < 10
}


First of all, when saying X and Y have a trusted relationship, it usually implies that X trusts Y and vice versa. This is not necessarily to do with the quality or guarantees of the link between them. I'm not just saying this to correct your definition, but because this trust relationship is important.

If in your case, A trusts B, and C also trusts B, then both A and C should trust that B delivers the messages that they sent without modification. There are many cryptographic examples that use a trusted 3rd party for exactly those kind of things.

If however, there's no trust in B. Only a trust in the security of the links to/from B, then it's a different story.

Encryption is probably not what you need here, or not ONLY what you need. If A and C share a key and encrypt messages between each other (via B), B won't be able to read the messages, but nothing stops it from changing the messages. Some times it's possible to make changes to encrypted message. For example, if I encrypt a message "I owe you $1000", it might be possible that B adds stuff to the message so after decryption it looks like "I owe you $10000", or change it to "I owe you $9000" (e.g. bit flipping attack). I wrote a little blog post describing this misconception in a little more detail, in case you're interested.

If you want to protect the message against modification, you should consider using some kind of a Message Authentication Code (MAC). Typically, you'd probably want to use HMAC - which uses a secure hash function to generate the MAC. This is like a signature on the message. Even the smallest modification will invalidate this signature, so it can be detected. Without knowing the key between A and C, B cannot forge this signature either.

Now nothing stops you from using Encryption + Signature. This will ensure both that those messages cannot be read nor modified.

With all that in mind, I'd still urge you not to develop/build your own solution, but rather find a suitable protocol or at the very least a library/package that provides those kind of mechanisms.


Is it ok to assume a user has opted-in to receive emails in an application where the main purpose is sending notifications

You have an argument for yes as the default, but you will have to go to the ICO/court if someone wants to challenge that. As the case law for GDPR is very thin on the ground, you are potentially the test case, which is a bad place to be.

If it goes to court, it will cost time and money. Even if it doesn't get to court, you will be paying lawers so it will cost time and money.

Personally I would choose option 3, not have a default and require the user to select yes or no.

Edit:

To clarify the following line gives a solid answer for why you would be paying lawers if someone challenged this is:

  The application is still usable if the user doesn't receive emails because the data which is present in the emails is visible inside a web-based interface

The argument is that you can sign up for the service and not want emails. This implies that signing up is not explicit consent.


Although that is possible, it's kinda hard to do that by yourself and it's for more advanced users. It requires lots of knowledge on low level programming and hardware.

It seems that what you want to accomplish here is the reprogramming of a USB flash drive's firmware to act as an HID (Human Interface Device). This is called a bad USB.

I found a tutorial called
How to Make Your Own Bad USB. The tutorial introduces you in more detail to what it is a bad USB and explains how to create one in Windows.
But the exploit described in this tutorial doesn't work on all USB flash drives. It has some specific requirements.

From the tutorial intro:

  Most common USB flash drives are exploitable due to the "Bad USB
  vulnerability". This allows us hackers to reprogram the
  microcontroller of them to act as a “Human Interface Device” (HID) /
  keyboard and perform custom keystrokes on our target machine. This
  scenario is often called “HID Payload Attack”, since you have to hand
  over your script to the Bad USB for the execution ( more on that later
  ). Even though almost every USB flash drive is exploitable, only a way
  to reprogram “Phison” microcontrollers has been released yet.

I haven't tried the tutorial, so I can't tell you if it will work, but nothing as trying it by yourself :)


SSL/TLS encryption is done end-to-end, meaning only each end can successfully decrypt the session.  The point of it being that Wireshark, or other network capture/sniffing tools, cannot eavesdrop on the data contained.

In a LAN or corporate environment, SSL interception looks like this:

Client workstations tries to go to https://somesite.
Inspection appliance sees this, and on-the-fly replaces https://somesite's certificate with a corporate certificate.
Each workstation on the network trusts the corporate certificate, so no error is displayed.
The client then encrypts the request with the corporate certificate, allowing the internal appliance to decrypt and inspect the traffic.
If all is well, the inspection appliance will re-encrypt the data using https://somesite's certificate, and then pass it on to the destination, and replies back to the workstation.

In such a way, the endpoints are really https://somesite and the inspection appliance.  Another session happens between the workstation and the inspection appliance which is essentially relayed to its final destination.

Essentially, the inspection appliance in this case is performing what is known as a "man-in-the-middle" attack, except ostensibly with permission to do so.


How does a HTTP client authenticate itself with a HTTP server?

Is it correct that there are various ways that a HTTP client can authenticate itself with a HTTP server?

Yes. There are many, many ways. Custom authentications schemes are common.

  Are the following such ways?

  authorization header: for various authorization protocols (e.g. basic, digest, ...)
  digital certificates: as used in HTTPS.
  specify user name and passwords in HTTP request's message body, by applying HTTP POST method on form data

Yes. Those are all ways authentication can happen. Although, nota bene, client certificate authentication usually involves the Authorization header with protocol = digest. Also sending username and password in a POST body is sloppy unless you're creating an account. It works, but it's sloppy. unusual unless the request is coming from an actual HTML form.

  Are they used individually or together? Are they used for the same or different purposes? When is each way used?

Only one authentication scheme is used at a time. Digest authentication is used when replay attacks are a real threat. Digest authentication involves a nonce such that the same MAC will not work twice. Basic authentication is more vulnerable to replay attacks but TLS encryption would need to be broken (or absent) to make this possible.

Client certificates are used when the server wants to check the veracity of the client's claimed identity using a trusted third party.

  In the second way, is digital certificates specified in some HTTP request header(s)? (In curl, it is specified via --cerf)

The client certificate itself would be specified in the body of an HTTP request. Client certificate authentication requires multiple requests and responses passed statefully.

  In the third way, when specify user name and passwords in HTTP request's message body, are they encrypted? Does the server know how to decrypt them?

They are encrypted if the request body itself is encrypted. This is the case in any https request. If you want details of the encryption and decryption system, read about TLS/SSL.


Hydra says it found a password, but doesn't show it

The passwords file that I've sent to Hydra contains an empty line (i.e. ""). When this value is sent to the web app, the response is "The password is empty", which is different from the "is incorrect" that it returns for most other passwords and that I sent to Hydra.

A similar thing happens when the password is "0", although, in this case, Hydra does show the attempted password.

For the time being, I removed those two entries from the passwords file, which avoids the false positive I was getting.

If someone knows a way to tell Hydra to support multiple "failure" strings, please let me know. Thanks.


Is there any simpler way to exploit such vulnerability

It would be more straightforward to simply integrate a PHP reverse shell into the db.php file; once it runs and connects to your listener, you'll be given shell-like access as root.


Which manufacturers who make BadUSB possible on their drives?

There isn't a clear list of what products are vulnerable, as manufacturers will use different chips even in one batch of products. So you'll never know what chip you have until you open the product.

They did however try to map this:

  They found an unpredictable patchwork of results. All of the USB storage controllers from Taiwanese firm Phison that Nohl tested, for instance, were vulnerable to reprogramming. Chips from ASmedia weren’t, Nohl’s tests found. Controller chips from fellow Taiwanese company Genesys that used the USB 2 standard were immune, but ones that used the newer USB 3 standard were susceptible. In other categories of device like USB hubs, keyboards, webcams and mice, the results produced an even messier Excel spreadsheet of “vulnerable,” “secure,” and “inconclusive.”

This list can be found here


iOS VPN profiles - are the signing certificates global? Can this be a MITM exploit?

No.
The profile you're required to install contains the parameter (and the certificates as well) to establish a secure tunnel between your endpoint and the VPN provider.
Once connection have been established,  at worst the ISP could perform (in abstract) the MITM attack because all your traffic is redirected throughout their server.
Perhaps, if you're concerned about privacy, keep in mind that all your browsing will be logged from VPN provider...

You can always have a look inside that certificates by using the apple configurator utility. You'll better understand how do they work on your phone policies.


What do do:

Check C:\Program Files\TeamViewer\ and C:\Users\UserName\AppData\Roaming\TeamViewer for the logs
Click on the tool kit symbol in the upper right corner click on the button Open Logfiles...
Create a support ticket on the TW site and send them the log

Relevant files for investigation:

Connections_incoming.txt - stores details of incoming connection that is established within the client PC. That means connected TeamViewer ID, the computer name from which connection established, time duration, connection type and connection unique ID - which is critical for any investigation.

TeamViewerX_Logfile.log -  stores each and every activity of TeamViewer with timestamps, remote system IP, TeamViewer ID and many other things. This log file is the complete history of all incoming and outgoing connections. Practically, it's everything you would need.

File deletion evidence you will find by comparing deletion timestamp with TW connection timestamp.


This sounds like a job for your eyes! Read the terms and conditions and see if they mention anything about your data in there. Remember YOU are using THEIR service, which means YOU have NO CONTROL over what you put on their service.

Realistically though it sounds like it's in their best interest to keep your private stuff private since it's easier on them, easier on you, and safer for both parties.

However without checking the ToS of both apps in depth you can't really know for sure. This at best is no more secure than encrypted email services, and at worse is not secure but that is the nature of using someone else's encryption service and not your own.


Could a neighbour see my traffic when we have cable Internet?

There are different network types, but one of the most common is passively switched fiber to the street.  In other words, somewhere around 32 customers share a common fiber line from the ISP.  The signal from the ISP is passively split out to reach all 32 houses, so all data that is transmitted from the ISP can be received at each house.  Information sent from each house should only go directly to the ISP.

That said, a few different things can limit this behavior.  The cable modems are configured by the ISP to only pick up the traffic addressed to you.  Similarly, it is becoming increasingly common for encryption to additionally be used rather than a simple address for the filtering of traffic.  If your ISP has switched to using the encrypted system, then each customer's cable modem is the only one that can decode the communication sent to it.


Would a Password Using All Possible Unicode Code Points Cause Problems in Traditional Hashing Algorithms, such as Bcrypt?

Not really. Hashing algorithms and Key derivation functions (side note: bcrypt is a KDF, not hash) works on bytes, not characters. This means instead of working on Unicode, it sees instead the utf-8 encoded bytes (or whatever encoding you use). So the hash/KDF itself wouldn't have any problems processing Unicode passwords.

However, Unicode had many different representations for the same characters. This is due to combining characters. Different OS and different text entry methods may produce different code points for the same characters. Application developers need to ensure that Unicode characters are normalized before passing it to bcrypt.

Another potential complication is that there are a different number of possible characters between unnormalized and normalized Unicode string. To produce a uniformly random Unicode password generation method, you need to generate uniformly over the normalized characters otherwise your password generation method may bias towards the characters that have multiple representations.


Servers: Why a separate device for a firewall, aside from reduction in IP spoofing or increase in performance

One reason for a separate device is so that you can remove everything that is not strictly required for the safe operation of the firewall. This reduces the number of possible attacks on the device which increases security.


Security Specification is a subtitle in a SRS(Software Requirements Specification) report.

Search "security" keyword in this sample SRS report to get better understanding:

http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_group2.pdf

Example specification from that document:

  ID: QR12

  TAG: CommunicationSecurity

  GIST: Security of the communication between the system and server.

  SCALE: The messages should be encrypted for log-in communications, so
  others cannot get user-name and password from those messages.

  METER: Attempts to get user-name and password through obtained
  messages on 1000 log-in session during testing.

  MUST: 100% of the Communication Messages in the communication of a
  log-in session should be encrypted. Communication Messages: Defined:
  Every exchanged of information between client and server.


What does an OpenPGP signature consist of?

OpenPGP Signatures

  The program outputs a small picture.sig file to the destination folder. What does this file contain?

  [...]

  But the .sig file should also contain entire certificate, or maybe a fingerprint of it. What does it contain? How does Kleopatra automatically choose the right certificate?

OpenPGP signatures can contain the original document, or not. It seems, Kleopatra created a so-called detached signature without the original document (on the command line, this is created running gpg --detach --sign).

OpenPGP signatures are calculated on a hash of the document to be signed. Technically, a signature is the hash of the document encrypted using the private key, so it can be decrypted with the public key. Given decryption yields the correct hashsum, the file must have been signed by somebody with access to the private key (hopefully, the key's owner). Remember, regular encryption works the other way round: the message (or to be more specific, a session key for symmetric encryption) gets encrypted using the public key, and can only be decrypted using the private key.

Furthermore, OpenPGP signatures include several meta data, amongst them the signing key's long key ID (not fingerprint). The full certificate/public key is not included, and needs to be fetched (for example, from the key server network) based on this ID when not available locally.

You can view the signature file's contents using the commands gpg --list-packets and pgpdump, offering similar outputs. pgpdump shows some more details when used together with the -l option (prints literal data, the original message if available) and -i (prints the actual numbers being results of crypto operations). An example for a file signed using my own key:

Old: Signature Packet(tag 2)(540 bytes)
    Ver 4 - new
    Sig type - Signature of a binary document(0x00).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA1(hash 2)
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Wed Jan 27 16:36:30 CET 2016
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0x8E78E44DFB1B55E9
    Hash left 2 bytes - 7d 3c
    RSA m^d mod n(4093 bits) - 18 1d d5 3f 6d f1 3e bb 93 08 8d 83 1a 3b a7 7a 70 56 f4 2c cb 92 cf a9 d1 f0 21 cd 7a f0 f8 5d 3e 75 46 d1 6a 14 56 27 a3 05 4a 6c 31 ee d4 8d 22 c6 d1 8a 41 6c 22 30 e4 90 19 1a 3f 18 ca 76 a3 1d d3 c1 f5 4a b7 54 9e 5f 83 dd 43 25 6b 80 66 65 34 36 80 4d 69 c7 fd 2a 3b 5b e8 a5 d8 c5 5a 26 a5 a8 19 b6 74 bc 47 69 e0 b7 a8 14 4b e7 51 5e e6 65 18 67 69 3e c8 5f 1b 78 8e f2 60 fa 15 a0 a0 be 7e 71 2f 68 19 07 af f7 d2 21 dc fb 3f f6 67 fd de eb ed c0 29 93 b7 59 5e 0a 35 1f 28 f4 89 51 43 a9 33 a9 f1 75 d6 6b 37 6b 3e a1 04 76 c5 43 b7 a8 05 3f 1a 08 b0 83 76 73 1e 61 78 e6 3b be 69 ca 60 93 5b e2 28 6c 53 65 63 ef 4b 06 df ce d4 81 47 ce 29 ea e3 06 a0 2a 13 30 98 00 8b 81 4d af 3d 5f 91 a0 26 e5 be 35 49 95 b3 7f 01 76 47 29 5e 8c 78 2b 22 c7 49 3a a1 b8 c5 48 ec 86 41 9b 34 65 a3 f1 3b f2 a4 8f 2c 2f 56 cd 72 86 42 7c 0d 08 51 8c 26 ee 91 1b 5a fc 6f 60 70 88 f8 d5 83 ea 89 c6 5c 13 0c 32 03 7b e2 82 50 77 f7 0d 2d 10 8c c9 95 05 b2 c7 99 ed 74 e4 46 75 95 00 6d d4 1b fc 4d 77 cf 7d f0 3f 1c 48 fa ab 8e 83 26 9c 09 e2 da e0 92 42 c6 8a df f6 3f 68 54 3a 02 49 d8 0a 1b 32 49 73 13 db 46 28 3a a1 aa 02 9a 9c cf 90 61 a5 ed 3f 7b 16 d3 64 1a cc 76 19 7e 84 62 ce 70 5a a7 cd be 40 28 72 f1 f0 16 7d fb 5a 84 69 d5 dc f9 f8 03 f7 5a ab a5 24 08 da a2 f3 14 1e e4 72 f9 62 72 d7 e0 52 07 b3 7c 1d 72 e5 6b 6f 43 9f 47 24 61 ab a3 c5 9a 6b c0 38 fb 8f 21 38 79 b5 2c 7f e8 1b 25 34 fd ce d5 2c e7 cd f8 57 43 b6 68 47 76 9e 03 70 f5 1e 30 21 83 12 bf fc d4 44 b9 dd 05 fc a0 2b f1 c0 56 3b 92 af 97 08 16 95 01 0d 12 c2
        -> PKCS-1

Trust

  Moreover, if I export this certificate, remove it from system and then import it; it will be impossible to check integrity of file until I won't sign this imported certificate by one of my own certificates.

This is another issue considering trust, and you have to discriminate between two operations: verifying a signature (in terms the signature was issued by a giving key, and the document was not tampered with) versus validating it (whether the key is trusted, based on certifications). As soon as the public key is available, you can very well test whether the signature was issued by this key (with other words, decrypt the hash with the public key and compare it), but you do not necessarily have the required information on whether to trust the key or not. One way to do so is comparing the key's fingerprint with the other party, and issuing a certification.


Disabling android application debug mode as a security practice

This is likely the same reason that you don't want to release a C/C++ program with the -g flags.  Unnecessary symbols are likely stripped away or obfuscated.   The build system might leave out certain security measures that will make debugging the application significantly easier.  Pro-guard build scripts are likely not included in a debug build.

The following are different types of data that can be kept in debug builds depending upon configuration.  Hopefully you can see why these would be helpful to someone looking to reverse engineering your application.

Debug Symbols

Debug symbols are select pieces of information that are stored within the debug binary.  All function names, file names, sometimes even line numbers are included.  This is so that when a program crashes and a debugger is attached all of this information can be included in stack traces.  It allows the programmer to pinpoint the line of code that is causing a bug.   A debug stack trace might look like the following (taken from this answer):

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
        at com.example.myproject.Author.getBookTitles(Author.java:25)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

A program without debug symbols will only know library definitions.  Like the following:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fd3700 (LWP 22532)]0x00007fffe10002b4 in ?? ()
(gdb) bt
#0  0x00007fffe10002b4 in ?? ()
#1  0x0000000000000202 in ?? ()
#2  0x00007fffe1000160 in ?? ()
#3  0x00007ffff66bd1a9 in execute_internal_vm_tests () at /home/bionix/Openjdk8/hotspot/src/share/vm/prims/jni.cpp:5128
#4  0x00007ffff7fd2550 in ?? ()
#5  0x00007ffff6b08bf8 in VM_Version::get_cpu_info_wrapper () at /home/bionix/Openjdk8/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

ProGuard in Android

Within the Android build scripts (Gradle) you'll find references to ProGuard.  ProGuard is used to optimize, reduce binary size, and obfuscate the code.  Because Java can be completely decompiled Android uses ProGuard to obfuscate the code.  Here's an example of code that has been obfuscated with ProGruard:

// Before
btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));

// After
d = a(d, n.a("new"));
e = a(e, n.a("open"));

You can view the full tutorial with links to source code.

From the Android documentation linked above:

  ProGuard is integrated into the Android build system, so you do not
  have to invoke it manually. ProGuard runs only when you build your
  application in release mode, so you do not have to deal with
  obfuscated code when you build your application in debug mode.

ProGuard is technically optional, but when using Android Studio it is enabled by default for Release builds.

Debug Logging

You should always have some mechanism in your code for removing debug messages from your release application.  Debug messages are stored as strings within the binary, and are not obfuscated.  Which means if you have a message like Log.d("Key " + super_secrey_key); a person analyzing the binary will now know where "Key " is referenced.  You've now provided context, and an interesting place to start analyzing.

There are several ways that you can remove debug logs, and one of them is by configuring ProGuard to strip them out for you.  There are also other libraries that you can use, or you can wrap your logging.  Either way it is important to make the distinction between debug and release for your log messages.


Ensuring a web-service only processes requests from specific computers

How concerned are you about an insider threat and how savvy would you expect insiders to be?  That's your biggest factor.  Almost any security mechanism you put on the machine's hard drive can be cracked if the attacker gets a hold of or too much access to the hard drive.  How long that will take will be a factor of how well you've secured the drive.

I can think of a lot of ways to do this:

IP filtering (spoofable)
set up IPSEC tunnels during install
Certificate based authentication
Require VPN authentication with something like a pseudo random key generator on a token

Anything is hackable, given the right threat.

Each mechanism has different ways of being attacked or compromised.  IP addresses can be spoofed, IP Sec tunnels or certificates can be compromised if the attacker gets into the hard drive or people do something dumb with the computer's security data.   Key generating tokens are great for being separate from the machine, but it requires COTS software and can get pricey.

Certificate authentication via client authenticated SSL is usually not too bad to configure - web servers will do a very simplistic authentication scenario, and you should be able to restrict your server to a list of clients that you trust based on the certificate's distinguished name.  If you use software certificates, it means you will have to install a separate private key for each client.  That means some level of diligent key management.  You can upload private keys into browsers or other certificate stores with a rule to the OS not to export the private key.  Some of this can be hacked or changed depending on the user's privileges, thus the question of insider threats.

If you limit your certificate authentication to SSL client auth, you won't have to change any of the logic of your web service unless you also have more specific privilege management requirements.


Where to submit collected malware from my honeypot?

http://cwsandbox.org/ explains it all. The product is now called Threat Track.

They have an uploader form.


What information can the ISP see when BitTorrent is in encrypted mode?

According to the inventor:

  The so-called ‘encryption’ of BitTorrent traffic isn’t really encryption, it’s obfuscation. It provides no anonymity whatsoever, and only temporarily evades traffic shaping.

And:

  As I’ve said before, protocol encryption is at best a temporary hack around ISP rate limiting, until identification techniques are put in place which use transfer patterns rather than packet inspection to identify traffic.

In this research paper, they

  show
  how even obfuscated application layer protocols, such as BitTorrent’s MSE protocol and Skype, can
  be identified by fingerprinting statistically measurable properties of TCP and UDP sessions.


How is Google Smart Lock different from the previous password management mechanism in Chrome?

One of the aspects of Smart Lock is the ability to have trusted devices.  For example, you can set your smartwatch as a trusted device for your phone, and then as long as the watch is within range, you don't need to enter a pin on your phone.  Seems a bit risky to me, so I don't use this functionality.

Other than that, it's pretty similar.  It can work with other apps as well as the Chrome browser though as well.  Not quite sure how this works, but it does say "certain mobile apps", so probably not in a very generic way.


What are the risks associated with relying on Mutual SSL & IP Filtering?

So assuming that by "mutual SSL" you mean that each end of the connection will generate a set of SSL certificates and then they will validate each others certificate when the connection is brought up, issues like IP spoofing should not be a concern, as if an attacker is able to spoof the IP address (which is actually not a trivial undertaking for a TCP connection) they would not be able to complete the SSL handshake as they would lack the SSL private keys which match the certificates held by the other end.

Some things I can think of that you would need to consider with this set-up

Initial communication of the certificates for each end of the connection.  You need to ensure that these aren't tampered with in transit.
Configuration of the SSL cipher suites on each end of the connection. You'll want to configure the servers at both ends of the connection to ensure that they don't support weak ciphers or deprecated protocols (some ideas for web servers here)
You'll need to ensure that you have policies in place for revoking/re-issuing certificates when they expire or if there is a breach in the security of one of the servers.


TVRA does it cover physical, cyber and information security?

Yes, it can and it is actually used for non-technical situations/ vulnerabilities.  You can thing at TVRA as a multi-layer procedure. There are companies who do this more thoroughly (covering each category/ layer), others do it as much as it justifies the costs, the allocated time and the urgency of it (for example if it is needed for regulations).  Most of the companies do this from business point of view, not from cyber-security point of view, even if the control measured that will be defined will be technical. So they take into account everything from who has access into the building, possible software authentication issues, human non technical mistakes and so on up to who could steal funds and how. As you said, every situation they can think of, not cyber security threats that apply. I think this is the usual approach. You think what are your assets (from  business point of view, again; and then, for each of them, you can think what can go wrong with your process so it would affect that asset in each way it could be affected.
There are other companies as well, usually with more resources, who prefer to go as much in depth as possible and to have a different document for each layer, both technical and non-technical such as one document for physical security, one for application security, one for network security and so on.


Risks of letting the browser open local/network file system listing

The part I don't like is the network path.

It should be ok if you chceck the path does not contain characters not allowed in path, that the path is a folder and that it is on the local machine.

However, if you allow remote file system, you are suddenly allowing the webpage to request a potentialy insecure connection to an unknown sysytem, that could send back a whole range of garbage to a black box app from Microsoft of all people. There are likely vulnerabilities in explorer that could be abused here.


Note: PREDICT transitioned to IMPACT

  Is this the end of malware use of DNS?

No.  Might tweak the landscape a little, but not hugely.

  It seems like the dataset in the news article could protect against
  both.

It's useful for catching people using malware that other people have caught before.  It is not useful for catching someone who sets up a burner domain just for their attack against you, or someone who hasn't been caught by someone else yet.

  DNS in the second use is harder to stop because it communicates via
  DNS itself instead of TCP/IP. Using a DNS server to try and filter
  traffic like this might be impractical.

There are "DNS firewalls" that perform this sort of blacklisting; perfectly practical.  However, again, severely limited by the rules of the "blacklist" game.

  So, cooperation like the "Predict" dataset makes malware use of DNS
  more risky because it will, on a daily basis, collect tens of
  thousands DNS queries and inform the world. It won't find them all, of
  course, but probably enough to make use of DNS more risky.

  So, knowing this, why use DNS at all?

Something like the PREDICT GT Malware Passive DNS dataset (hereafter PREDICT-GTMPDNS) incrementally increases the risk, but I certainly wouldn't say it significantly increases the risk.  Malicious operators are comfortable operating in a world where their DNS-based web sites can be interdicted by filtering proxies, where their mail servers can be blocking using RBL, and where firewall rule routinely try to restrict egress traffic.

One of the reasons they use DNS is that it's difficult to block at egress - due to the indirect nature of DNS, you can't easily block some of it without blocking all of it.  You can even have DNS pointing somewhere benign, then cut it over to somewhere malicious briefly while you use it, then point it back... hard to do with an IP, easy with DNS.

  Wouldn't it be easier and safer from the malware's point of view for
  it to simply contact one or more direct IP addresses instead of using
  DNS?

Historically, the inflexibility of direct IP addressing has lessened it's attractiveness.  PREDICT-GTMPDNS could help reduce DNS's attractiveness, but not enough to rule it out.

  Why not just skip registering domains and just use IP addresses that
  blink in and out of existence and serve the same purpose?

It's harder to have IP addresses "blink in and out of existence" than it is domains.  And once you send out the malware with a hard-coded address, it's stuck on that address, and you can't just blink it out of existence without shutting yourself off.

  Perhaps the problem of slowing down DNS by inpspecting DNS traffic
  still prevent full use of a dataset like "Predict"?

The DNS inspection cost is low enough not to be an issue... the real problem, as with any blacklist, is the sample size and turnaround time.  If your database inputs cover 50% of the malware out there, that's insanely awesome... and still leaves one out of every two exploits free to maraud.  And let's say malware is found, submitted, run, and indexed a day after release... that's 24 hours in which that malware can run free and clear before the database catches up.

In reality, I think the inputs to PREDICT-GTMPDNS will be both less comprehensive and slower to catch up with new malware releases.  Playing catch-up sucks.

That's not to say PREDICT-GTMPDNS isn't an awesome idea.  It is.  But it's not any kind of silver bullet.


It has already been agreed that there is too little information to work with in this question, but I'd still like to point out the two most plausible and non-malicious explanations in case the question pops up again.

The email you sent to the Vendor was not properly handled by Yourself.

Not meaning to point finger, but at any request for help, this should be the first suspicion. The "neither DKIM nor SPF pass" does not automatically say that both "failed". You may have one fail and one that wasn't configured at all for your domain.

This is of course the reason to have DMARC reports at all. Even if you seem to be sure of your setup, please do send a test email to e.g. gmail and read through the headers of the recipient email.

The Vendor has an email forwarding system that isn't properly configured for DMARC.

This is unfortunately more common than one would hope. See reasons for reference:
https://www.dmarcanalyzer.com/forwarding-within-dmarc/

It is sometimes said that it's only a problem for SPF, but forwarders may change both headers and body for internal and perfectly innocent (but less valid) reasons. If the forwarder keeps your domain as From-address the DMARC report will be sent to you.

  The next day, Postmark sent me my weekly DMARC report - and it
  contained 2 failed entries originating from this vendor's domain,
  saying that both SPF and DKIM failed.

I'm not familiar with Postmark, but for each fail it should be possible to see:

a) Which server reported the fail
b) What was the originating sender server
c) What was the DKIM signature domain
d) What was the SPF verification domain

Using this information it should be possible to learn more about the "spoof". When you say "originating from this Vendor domain" I can't clearly assume which of a-d you mean.

As also already pointed out, in both of these cases your email may have been lost and your request to the Vendor needs to be retried. Sending a follow-up email is a good way to check if the same report appear again of if it was a one-time thing.

In any case I'd say it is not a bad idea to ask the Vendor about the "spoof". They can probably help you with an explanation and you decide if you are willing to trust them. It may also be that they are unaware of a mail configuration problem they have.


What are some tips to defend against router exploits like the ones used from routersploit?

Keep the firmware up-to-date, research the possible exploits before buying the router, do a port scan from inside and outside the LAN to see what is exposed on different interfaces, disable remote access to the admin pannel (or filter it by a static ip that you know only you or authorized people can send pakets through).
Lastly, do a security assesment on the software, most decent routers actually run a modified linux version, custom made for them, and you can get a root shell by soldering some pins on the serial console and connecting to them using a UART to usb adapter (finding the baud rate and the right pins might be tricky at first, but there are tools and tutorials out there), you can significantly increase the security of your router by disabling unwanted services, unwanted iptable rules and super admin accounts (funny story here, I have found such an account on a router deployed by the ISP, the super user account was so baked in that changing the password bricked the device and it was the only account that could login into SSH).
Keep in mind that most attacks will come from publicly available exploits, treat your router as if it were your PC or your production server.


How do you socialize online and avoid facial recognition and other privacy breaching-tactics

Face detection software is ubiquitous. There's no way to put up an image of your face and allow humans to recognize it but not computers. If you're putting your image online, expect it to be mined.
You can make it a little more difficult for facial recognition software to know that it's looking at a face (which is sufficient to prevent it from knowing who it is looking at) by using certain techniques:

Avoid symmetry. Facial recognition software loves symmetry. Take up an asymmetric style.
If you're a woman, wear makeup that hides contours, sharp lines, and shadows.
If you're a man, grow a beard. It hides the facial features that are most recognizable.

None of this is bulletproof. It just slows down the inevitable. On the upside, consider just how big of a deal it is that this data is out there and whether or not it's already out there. If you're posting to a dating site, then it seems unavoidable that you'll be using your real name or providing personally identifiable information. That's a sacrifice you must make if you want the convenience of online dating.


You are assuming that the purpose of a fake AP is to collect the password of the real AP. That is incorrect. The purpose of the fake AP is to get the target's password to websites, like their email, bank, etc.

You disconnect the target from the real AP, connect them to you (without password), then as they go to their websites, you "sniff" their credentials.


How to check if a user's password has appeared in a breach?

Perhaps the most popular password breach checking site, HaveIBeenPwned, supports a RESTful API which you can query as part of your password workflow.  It allows you to search a subset of the password hash and returns a set of possible matches for you to compare against the full hash; see this section of the documentation.

Because HaveIBeenPwned is updated with new breaches as they become available, you do not need to worry about monitoring breaches to take advantage of them.


Just isolating filesystem access is not enough by itself to protect the rest of the system, and it's also notoriously hard to do right (chroot can be pretty easily escaped, SELinux is a pain in the arse to set up, etc).  Among other potential means of attack you have:

IPC objects (semaphores, POSIX message queues, signals, etc).  There's no easy way to limit which process can manipulate which IPC objects, but globally blocking them will actually break many legitimate programs.
Network access.  This is easy to block, but obviously is not covered by just restricting filesystem access.
Certain types of resource limitations are actually pretty easy to side-step as a regular user (CPU affinity for example).
Without some effort on your part, your new users will have pretty easy access to certain types of hardware on the system.
Even aside from the above, there are a lot of system calls that should never be called by regular user code but can be (vm86 and iopl are probably two of the best examples).

Ideally, assuming you don't want to deal with complicated manual setup, look into a tool like firejail.  While it's not designed for this exact use case, it should be pretty trivial to adapt to it, and it's dead simple to configure compared to most sandbox software.  With a sane configuration, firejail can:

Securely restrict filesystem access in a way that's easy to configure.
Similarly protect IPC objects.
Restrict usage of capabilities.
Limit network access, possibly using a completely different network configuration from the host system.
Force specific CPU affinity.
Spoof a variety of common identifying information for the system (hostname, machine ID, data reported by uname, etc).
Disallow execution of memory that is or was writable (only on some architectures).
Disable access to a wide variety of hardware that may otherwise be accessible.
Explicitly prevent execution of code in certain directories.
Make certain directories ephemeral (they will lose state when the sandbox closes, great to ensure that temporary files get cleaned up).
Set and enforce various resource usage limits for the processes inside the sandbox.
Explicitly block specific system calls (the default profile with this enabled will block most of the ones that aren't needed by most applications and are a potential security risk).


Typed password in the username text box but didn't hit enter. Should I still change the password?

I'm a frontend developer and have made many forms over the years. First, some baseline info:

Form data is not generally saved or processed unless its physically submitted. This is also a browser default for security of the user.
Form data is not even entered into any browser cache unless submitted.

However, the default behavior can be changed by the developer of the website using JavaScript. This could include posting the data in the user name field to their backend as you're typing the data without submitting it.

To check this you can open up your browser's developer tools console and check the network tab. With it open, type in the username field. Then leave it for a minute to see if there's any polling to the server happening. If any JS is firing off data to any backend you will see this as requests stacking up in the Network tab.

Another possible way your information could be compromised by typing your password into your username field could be session recording services. If the website employs one of these services (such as FullStory, Matomo, etc.) then it's possible your input was recorded and can be reviewed by someone later. You can peruse their JavaScript libraries and identify each script and what it does.

Doing the above steps should give you some piece of mind as to the safety of your password. Especially if it's not easily changeable.

Bottom Line

If it's a trivial task to update your password, you may as well do it out of an abundance of caution. It would probably end up being easier than to go through all the investigation steps I mentioned above.


2FA on Stack Exchange, Where Is It Or What I am Missing?

StackExchange does not natively support MFA
As the answer to the question you linked to suggests, SSO providers like Google and Facebook support MFA.


Private messages for an ios app - how secure is this system?

Your scheme isn't very secure.

Someone could mount a MITM attack by intercepting the public key and replacing it by its own. After that, he would be free to relay and re-encrypt all messages without anyone being the wiser.

You need to have some authentication component included in your key exchange so that you can guarantee the ownership of the public key you're using.


Is it possible to protect your software and similar from being cracked?

As long as the user has full control of the hardware where the software is running on (i.e. typical PC) it is impossible to fully protect the software. At most one can make it harder with code obfuscation or similar techniques.

To get better protection one has to move at least some essential parts of the software into an area which can not be controlled or reverse engineered by the user, i.e. specialized tamper resistant hardware or a remote system which is under your control. An example for hardware are smart cards which only allow operations using a secret key but don't give access to the key itself. An example for remote system is the typical setup of a browser and a web server where the business logic is running on the server and only the frontend is running in the browser. This way the software implementing the business logic can not be directly accessed and reverse engineered by the client. An attacker is thus restricted to a black box approach, i.e. can only deduct the functionality by comparing input and output and maybe replicate part of the functionality in its own software. But the attacker cannot access, modify or copy the original software.


Is there any advantage to rebooting my computer after handling sensitive information?

No, it doesn't. The value might still be stored even through reboot(the physical nature of RAM leads to this). While user level applications will not receive access to the memory(it will be zeroed out when allocated), any compromise that can read the raw RAM will still be able to find it.

HOWEVER this is the wrong question to ask. Really the problem is if you're compromised to that extent, it's not your system anymore. They could sit back, relax, and slowly siphon the information as you use it and you may never know. At that point rebooting or even shutting down and waiting for RAM to clear won't do anything. They already have it.


A whois of the www.google.co.kr domain seems to indicate that it is legitimately Google.  Why it was redirecting through there is a bit of a mystery.  I do know that there is a feature on a lot of phones that will us the Google account of the phone.  It is possible that the vendor that wrote the software was Korean and simply used the Google server from their home country to do the redirect.  I'd certainly keep an eye on it, but I don't see how this particular thing could be an attack from what you've described.


Server is returning an unrecognized error message?

HTTPS intercepting proxies are commonplace in many companies. But also many desktop antivirus products ship with a proxy to intercept and scan HTTPS traffic. And sometimes malware does it too. These proxies can then scan, modify or replace any traffic. This is used for valid purposes to block malware or data leakage (which might result in the strange errors you see) and for invalid purposes for example to inject advertisement into the traffic.

See also Is it common practice for companies to MITM HTTPS traffic?.


What extra protection is added to an REST API over HTTPS by the use of some kind of HMAC?

HTTPS is HTTP-within-SSL and SSL already enforces integrity checks -- indeed, it does so with HMAC (see section 6.2.3).

Using Basic authentication is safe within SSL, and sufficient. You don't need an extra HMAC. The method shown by AWS is meant to provide some sort of authentication in situations where data travels unprotected, in order to prevent the client credentials from travelling as cleartext, because an eavesdropper could otherwise learn them; SSL provides both confidentiality and integrity, making this point moot.


How to look up a file that has been split into segments in a memory snapshot

I don't know that there is any way to know where the fragments are stored within memory (or the memory snapshot) like there might be if it were in a file system. So searching on each may be the only way there. As for automating that process, I don't know of anything available.

You can use hex editing software to do the searching, copying out blocks of data into separate files, and then putting them together into a single file. It will be a lot of manual work, but not overwhelming for just 80 blocks. We've written software that will do similar in an automated fashion (and actually that middle step is not needed when offsets are used), but it isn't publicly available unfortunately. However, I mention that because you may want to consider a custom software solution if you do this many times. But if you just are doing it once, manually would be just fine.

I put a couple hex editor links below. I believe FTK Imager is a Windows software so here are some Windows choices-

Hex Workshop http://www.hexworkshop.com/ (this is mentioned in FTK Imager user guide)
WinHex https://www.x-ways.net/winhex/