Exploiting HTTP redirect function via the Host header

This is an old question, but for the sake of completeness, I'll add some thoughts.
The reference in term of hosts headers attack is Practical Host header attacks (2013) and is still valid.
Attackers would quite certainly use the absolute-uri trick to inject the bad header and be sure to reach the right virtualhost. But in some cases, this is not even required (as may be in your current application, where any request with any Host header is accepted given that the HTTP query is made on the right IP)
# instead of
  GET /uri HTTP/1.1
  Host: good.name.com
# they would use
  GET http://good.name.com/uri HTTP/1.1
  Host: evil.com

And this could be exploited in mainly 3 ways (mainly, but that's open to more ideas):

cache poisoning: if your application feeds the page with a domain taken from the request (when rebuilding absolute URLs in HTML links) then there's maybe a chance that these bad domains end in the cached version of the page for /uri. Quite hard to perform (the cache may end up caching the page as http://good.name.com/uri and not /uri.
bad links in email: say your application is sending a password reset one-time link, with the URL taken from the host header, then the attacker could hope that someone will click the link with evil.com domain. But it means someone clicking on a reset password email link without asking for a password reset (as the attacker performed the bad query)
CRLF injection, as with all injected headers, one goal could be to get a response where a very bad host entry (containing CRLF, or %0d%0a (\r\n)) would be reused without filtering on the response headers. Leading to headers injection in the response.

As @Steffen Ullrich noted there's no way to lead an innocent user to perform the attack (especially because the browser uses the hostname DNS resolution to find the IP of the web server). So the only victim seems to be the attacker. But anyway, the attack target is asynchronous. It's not like an XSS attack, the target is not the user receiving the response. In cache poisoning it's quite obvious (target is the cache), in password reset email is used to carry the attack to the victim, and in CRLF injection we enter the HTTP response splitting and HTTP smuggling zone, where consequences are quite tricky, but they can lead to cache poisoning, deny of service, socket poisoning, incomplete requests, etc. The target is a reverse proxy, and the attack will later expand to other users via this proxy.


The best possible scheme would be having that one encryption key for every user, similar to an authorization code given out for Microsoft products.  The only difference would be that every single program you give out would have to have a different encryption key embedded into it.

That would be the only way to somewhat secure the encrypted data.

Either way you are breaking Kerckhoffs's principle (2. Enemy knows the system), so it would probably be good to implement run time decryption / obfuscation of the class that will be decrypting the data file.  It won't stop people who really want to get it, but it would definitely put up a barrier.

There's no good way of 100% securing your program.


How bad is it to *not* reboot a server after kernel updates?

You aren't running the new kernel until your reboot, so in terms of security the vulnerability you'd patch by updating the kernel isn't patched until you reboot.

Linux 4.0 has support for no-reboot patching. It's still in very early stages and the userspace tools (systemd, etc) don't yet support it but the code is there and hopefully it'll become widely supported soon.

Another solution would be to use something like Uptrack that can update some parts of the kernel without rebooting, but that requires a subscription and is only available for some distrubutions.


How can I securily use a pre-owned smartphone?

Depends on the risks you are trying to mitigate. General rule of thumb is that once the evil maid has access to the end point, it's not a trusted platform.

Free from irregular spyware and presumably no other untrusted devices
on the handset. The risk is to the confidentiality of your data
mainly I think.  There is some risk to integrity and some to
availability but I think mainly its confidentiality.
Risk to your
personal freedoms.  There is a chance that the phone was used by a
criminal or actor being investigated by an agency.  Your phone will
have the same IMEI and therefore there is a risk that an agency might
want to speak with you and ask you to prove that you were not the
original owner.  Probably low impact to you, but no way of knowing
who comes a-knocking.
Risk to availability.  Battery. Dead. No call.
Risk of "I just can't get the damn thing out of Chinese/Russian/French/Yahoo mode".

If the phone you buy is rooted then, meh, game over.  There is practically no way you can know what is on the phone or what has been installed.

If it has not been rooted then later versions of Android claim to factory reset everything. But there is some research link to suggest that this is not the case and there there is data remanence after a reset.  You could flash from a known-good ROM but even then you can't know for sure if your specific hardware hasn't got something lurking.

So to answer your question, the answer is : Probably.

If you only use the phone for making calls on a PAYG contract then your maximum exposure is your remaining credit plus your call history. A factory reset is OK because low likelihood x low impact = low risk

If you use your phone for secret squirrel work then nope, you can't use it.  That's why UK Government has Good Practice Guides on the re-use of devices and the sanitisation required between users or different threat levels. Low likelihood x very high impact = high risk, plus it's government so no choice.

If you use it for calling plus some interweb stuff then it's possible your phone has a backdoor but it's very unlikely.  Not a probability of zero but close to it (happy to see some real peer reviewed data on the number of second-hand phones on sale with malware that has persisted over a factory reset though, as I could be wrong).  Add in that you will only be buying a second hand late model with some of the later protections then the low probability x medium impact = low-medium risk offsets the currency.

(In my final analysis and IRL for me the battery life makes it almost uneconomic for me to bother with a second hand phone because a battery is typically rated for 10,000 cycles which is about two years after which you have to buy a new phone anyway.)

edit: see this SE question
Cambridge University paper on Android factory reset still up to date?


Web server responding to an HTTP request from a spoofed IP address

It is usually very hard to spoof TCP, which is the underlying protocol of HTTP (when ignoring QUIC, which has its own spoofing protection). But it is not impossible and it might be easier in some setups: see this link about quick blind TCP connection spoofing provided by  ximaera for more information.

But, in case the attacker manages to successfully established a TCP connection with a spoofed source IP, the server will send its response to the claimed (spoofed) source of the connection. Since there is no matching association at the claimed target the packets sent by the server will either result in a RST from the spoofed target or will simply be lost. Since TCP relies on ACK from the peer (i.e. HTTP client in this case) to signal that it received some data and this ACK is not sent the server will realize that  the connection is broken. And while QUIC is a different protocol than TCP the results will be similar.


How to exploit a Use-After-Free vulnerability?

There are programming languages like C or C++ where the program has to manually allocate and deallocate memory to store its data. After memory was deallocated, that memory can be reused to store other data. However, even after a C program has officially deallocated a block of memory, it can still read from it and write to it. If this happens it is practically always an unintended bug. In many cases the compiler and the operating system can detect when this happens and have the program crash, but it is not possible to catch every eventuality.

That means the program believes it is reading or writing one piece of data (which should actually be no longer relevant), but does this with some other, completely unrelated piece of data which was stored there in the meantime. This can, for example, result in data being overwritten with data provided by the attacker or result in confidential data being read and finding its way into the program's output.

Regarding how to exploit this: There is no universally applicable answer because the situations in which use-after-free's occur are heavily dependent on the application.


Why does OpenVAS warn about PHP 5 when I am running PHP 7?

This VT is doing an "active" HTTP POST request to the mentioned URL http://domain:port/ with the following data:

HTTP Method: POST
POST body: <?php phpinfo();?>

to the following two URLs (one after another):

URL1: http://domain:port/?-dallow_url_include%3don+-dauto_prepend_file%3dphp://input
URL2: http://domain:port/?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E

and is checking if the remote host is answering with a <title>phpinfo() to this request. To avoid that any false positives are happening it checks if any of the URL tested are previously detected to respond with such a <title>phpinfo() string.

If you're getting a vulnerability report this could mean a few things:

The web server / application itself is vulnerable against such kind of attacks even if not running PHP via CGI.
Newer versions of PHP are again vulnerable against such kind of attacks.
The URL http://domain:port/ is always returning <title>phpinfo() and the previous detection of this to avoid false positives failed.

The VT will be improved in the next few days to give out a little bit more info about the check done but the info above should be enough to verify the vulnerability on that specific host.

Disclaimer: VT Dev @ Greenbone (Maintainer of GVM, former OpenVAS)


Is this integer overflow vulnerability exploitable?

Yes

You don't need to use -1, any value larger than 20 will allow you to overflow the buffer.

It will depend on the next instructions and the mitigations set by the compiler, but from this point on you can probably overwrite the return address and execute a shell code provided as the second parameter.


How to use an old PC as a firewall on a tight budget?

This is all predicated on using the "old pc running Win Server 2008" (I assume you mean Microsoft Windows Server 2008) as a gateway.

This predicate poses a number of issues:

MSWindows in it's various incarnations, is heavier on resources - running the most up to date (i.e. feature rich) version of the operating system on old hardware is hardly a recipe for good performance / reliability.
IMHO, BSD and Linux operating systems offer a far greater set of facilities for networking / managing security out of the box then MSWindows does
MSWindows Firewalls are typically implemented within or on top of winsock.dll, which can leave a lot of the network stack exposed compared with iptables / ipfw
There is a far more diverse and complete ecosystem of free code available for Linux / BSD than for MSWindows
Point 4 is particularly true to applied to free software (as defined by Gnu project et al) where the guarantee of access to the source code gives better opportunity for review of the quality of a product (yes there's lots of freeware/shareware for MSWindows - but where's the source code?)
This ecosystem, in addition to peer review, also gives rise to diverse community support

The argument that the skills for running, say a Linux server are not as widely available in the organisation compared with MSWindows skills is not valid: to add value whoever manages this must understand about security, network protocols, policy planning and implementation....what operating system is used to deploy the implementation on is a very small detail in terms of skill requirement.

So forget about freeware/shareware and go look for "Free software".


Laptop battery dies, only IT is allowed to access machine after plugging in

If the computer is not allowed to be turned off, monitoring software (and possibly other hardware components) can be used to monitor things such as the removal of HDDs, RAM, and/or other chips. If the battery dies, there's no power to the system so no monitoring can take place - thereby requiring a hardware check to make sure nothing has happened. This is just one possibility I suppose.

Update: it's also possible the BIOS keeps logs of hardware changes which the OS (and thus your employer's monitoring software) can access. A dead battery would cause a discontinuity in such a log as parts could be removed and reinserted without its knowledge.


what are good requirements for a password

Bruce Schneier has written a nice essay about the subject, I suggest taking a look at that. In a nutshell:

Most users tend to use similar patterns for their passwords, and there are tools which are pretty good at guessing them (up to 65% success rates).

This pattern, as satirized here, consists of using a dictionary word (common or not) with some letters substituted according to common rules (such as 4 for A), followed by (or more rarely prefixed by) a simple affix (usually numeric).
The "danger" of such passwords is that they provide an illusion of complexity and thus security, while in fact they are relatively easy to crack (assuming an off-line attacker).

Passwords that contain biographical data (such as names, addresses, ZIP codes) are substantially easier to crack, so users should be discouraged from using them.
Very short passwords (4 characters or less) are also susceptible to exhaustive searches.
A good password, thus, should have reasonable length (8 characters as reccomended by OWASP might be ok, but in principle the longer the better) and not follow an easily recognizable pattern.

Alternatively, it could follow a pattern, but one that can not be easily replicated. An example would be thinking in a sentence, and creating a password from the first letters of each word in that sentence.
Another option (also suggested in the essay, though personally I disagree with it) is putting the affix (the numeric sequence) in the middle of the root (the word), or using two words joined together with the affix.

The most important of it all IMHO is not having a "maximum password length" or, if unavoidable, to leave that maximum at a very high value (such as 64 characters). Since you won't be storing the password itself, instead storing a secure hash of it, the length shouldn't affect your back-end design.

(Also don't try to "force" too much password complexity, or your users will begin to actively fight you - by writing down their passwords for instance)


The issue that usually comes up when talking about client-side hashing is that an attacker who has breached the database can merely pass the hashes to the server to authenticate.  However, this scheme doesn't allow use of the hash for authentication, just the initial account creation, so it doesn't fall into that trap.

I've seen this sort of thing used in the context of Apache htpasswd files; users generate a digest and send it on a relatively insecure channel (e.g. email) to the systems administrator, who then adds it to the server configuration.  While a system involving basic or digest auth isn't the pinnacle of computer security, this shows that it's not an entirely novel approach, and has had at least some attention.

Given the description as you put it, I don't see any obvious issues.  There can of course be implementation issues, like a bug that allows feeding the hash instead of the password for authentication.  And since the initial connection isn't trusted, it's probably a bit easier for an attacker to obtain a password hash (that they can then try to crack or generate a collision for).  But those aren't issues with the scheme itself, or major issues.


Can a webpage text saved in pdf file compromise machines

No, this is not possible as far as I know. I cannot think of a vector that would allow that to happen.

However, it is a rule that ALL user input is considered untrusted and must be validated before use. That still applies here. A classic example is allowing unrestricted length inputs (a non-browser client can ignore any HTML "restrictions" on length) to be submitted that causes a buffer overflow on the web server.

So always sanitise and validate any input to the server before you use it.


How Do AVs differentiate between normal cryptographic modules and viruses crypters

Crypters and legit crypto common in apps are very different and have very different signatures.

Binary executables can't just be "encrypted" because they won't be able to be executed by the CPU or OS. Crypters are an obfuscation tool used to turn your code into very hard to read and reverse engineer code. This is done with a variety of methods and most don't involve the kind of "crypto" you would find in legit applications.


Does the choice of protocol affect the efficiency of a DOS attack?

In principle a DDOS attack can send completely legitimate requests and thus overload the server. For example, just use a botnet to visit some persons blog and the server will potentially collapse under the load. There is no real way to protect against this because every request looks like a real request.

However, the often more interesting case is to intentionally violate the protocol on some level to boost the efficiency of an attack. For example opening a lot of TCP connections to a server but never sending anything is very cheap for a client but the server might run out of connections (in whichever sense) because he is waiting for them to time out. These kinds of problems can often be mitigated using appropriate safeguards in code and configuration settings.

So to answer your question: (D)DOS attacks can be carried out with any applicable protocol and often become more powerful by intentionally violating parts of the protocol.


Single Page Application session management

Looking at the two options you presented, sessionStorage or HttpOnly cookies, there is a trade-off.   You are correct that if you use cookies, you need a CSRF token, and if you use sessionStorage and use that as the source for your header, you do not.

However, what OWASP is concerned about with sessionStorage, is that an XSS vulnerability allows an attack to extract authenticated sessions.   With an HttpOnly cookie, it does not.   Given the prevalence of XSS on the web today, this is a threat to consider seriously.

So, while sessionStorage would be the simpler option, and may well work with little modification to code you currently have in place, the HttpOnly cookie plus an anti-CSRF token would be the more secure approach.  You have to decide if the extra effort is worth it to you, for your application.


Is it possible to intercept traffic by using a WAN facing DHCP server on an ISPs cable network?

This (old) talk gives a lot of background information about DOCSIS, how the protocol works and discusses weaknesses in the cable company implementations:

https://www.youtube.com/watch?v=BBtdZDah6iE

The DOCSIS spec is reasonably readable and available online.  The presentation is helpful at getting a high level understanding of how it works and how it doesn't.

Hopefully somebody can provide a more complete answer.


It's decent! After all nothing is secure...

By that I mean:

In 2013 in a public audit it was broken ONLY with targeted malware that affected the OS Kernel, OS User Mode at an Sandbox Bypass level and Key logging, Remote Webcam/MIC Access, Clipboard Hijack, Screen Scraping, Steal Files (in some cases), Network Shares Access at an Sandbox Leakage level. Those problems were detected in 2013 and since then there were many security and optimization improvements.

You can read there last public security report at: https://bromiumlabs.files.wordpress.com/2013/07/application_sandboxes_a_pen_tester_s_perspective2.pdf


Making a Windows cert say it's purpose is "Ensures the identity of a remote computer"

If I could use OpenSSL I'd just add following lines to openssl.conf:

keyUsage = digitalSignature
extendedKeyUsage=serverAuth

but don't know how add extendedKeyUsage in PHPSecLib


JWT access tokens: Too much information?

It's all dependent on whether the RP actually needs the information provided in the token to evaluate permissions.

You might have privacy issues if it's purely identifying information. The fact that it's a dual use token is problematic, but whether this actually poses a problem needs to be evaluated on a case by case basis.

Edit: Delegation of permissions is an unfortunate capability because these tokens are often bearer tokens -- whoever has the token can use the token. There's no way to separate this permission from the token, unless there's an explicit mechanism to delegate. In the OAuth world this is on-behalf-of (though I'm not sure how widespread it's used or accepted outside of Microsoft technologies).

The audience doesn't apply here because the audience dictates what service you're allowed to communicate to, not from. In order for this to be blocked the token needs to include ways to authenticate the client, and the client needs to authenticate to the service using a separate mechanism.


It depends on how you copy them.

If you do a bitwise copy, aka exactly replicating every single bit from one disk to the other, you are copying over "slack space" which is where the recovery tool will work.
If you do a file copy, then the empty space of the disk is ignored, and only the segments of data attached to a file header will copy over. The recovery tool cannot see the slack space attached to the other disk.


Can one reliably show HTTPS status in browser (not just the lock in the URL bar)?

No, this isn't possible. Anything you display on a webpage can be manipulated easily, using things like Javascript and thus cannot be trusted.

The padlock on the browser is the only reliable indication that HTTPS is working on a page.


PCI-DSS requirements regarding long exposure to critical vulnerability (RCE)

Note : Not a QSA, but some PCI experience.

The section relevant here is section 6, especially 6.1 "Is there a process to identify security vulnerabilities" and especially 6.2.b "Are critical security patches installed within one month of release?" (though the whole section is relevant to the discussion)

To comply with PCI DSS, you must have a formal process for identifying security vulnerabilities, both in third party software and in software you write, through checking the National Vulnerability Database or other sources, through secure code reviews, through vulnerability testing.  You must also have a process for ranking those vulnerabilities - most places use the Common Vulnerability Scoring System but it isn't a requirement.  And once those are scored, you must have a process that determines when each must be fixed by - and that process must include fixing critical vulnerabilities within a month.

And once you have all these processes, you must actually follow them.

I am not aware of any requirements for disclosure within the PCI DSS standard, though industry best practice is to have policies defined for when to disclose to who and there may be local laws (California has some, for instance) that require disclosure in certain circumstances. I am a personal believer in defaulting to disclose when exploits happen.


JWTs are a good way to approach this. My two cents would be to sanitize any and all user input on the client side (reduces surface area for XSS attacks), and use cookies as a medium for transporting the token between client and server. Set the token expiration times to something where, even if it gets stolen, it won't be useful for long. You can lookup XSS prevention cheat sheets which will provide more information regarding XSS prevention. And finally, if this is a production level app, have it pentested or scanned by a tool like Mozilla Observatory. Hope this helps.


Challenging challenge: client-side password hashing and server-side password verification

I think you're wasting your time and adding needless complexity.  I don't think the reasons you give are sufficient to warrant this kind of client-side password hashing mechanism.

Instead, I suggest keeping it simple.  Send the password over a SSL-encrypted link.  When it comes to security, simple is good.  Needless complexity is the enemy of security, because it introduces the opportunity for bugs and mistakes.

Save your energy for other security tasks that will address more realistic threats.  There's a limited amount of time and energy and budget one can spend on improving security; best to spend it on the places that will yield the greatest bang for the buck (the greatest improvement in security, given the investment).  I think you'll find there are other ways you could spend your hardening your system that will improve security more.

If you're worried about whether the server-side code is handling the password appropriately, then review that code carefully: it should be contained to within a very small chunk of code.  This should take care of risks like, e.g., the server logging cleartext passwords: you just read every line of code that's involved with password checking or that reads the password, make sure the first thing it does is to hash the password appropriately, and make sure that all it does is check the password for validity and return true or false.  If your system is well-designed, this should be pretty straightforward to verify through code review.  If the code isn't well-designed, maybe now would be a good time to fix that.


What is a reasonable expiry for user authentication certificates?

Real-life certificates have a neat concept called revocation. It is a way to propagate (in a secure way) the information that a given certificate, though apparently legit and kosher and with all the correct signatures, should not be trusted anymore. That's a kind of "oops" functionality. In X.509, this uses Certificate Revocation Lists and OCSP.

The underlying idea is that mishaps do happen occasionally, in particular stolen keys. Revocation is then a damage containment procedure, which is triggered when a problem of that kind is detected. The important property is that it is a manual procedure: it happens when humans decide it. So it has an inherent, unavoidable latency. Therefore, there is no need for revocation information to be "extremely fresh": CRL which are published, say, twice per day, will be enough, because it is illusory to expect a better reaction time to stolen keys.

Expiration can replace revocation if it is short enough. If certificates are short-lived, then revocation is not needed. How short is "short" ? By the reasoning above, revocation is not needed if the expiration time is shorter than the CRL publication interval that we would choose, if we had to publish CRL. By the reasoning above, 12 hours are short enough.

Therefore you may expire your authentication certificates after 12 hours. Since humans sleep at night, you cannot really expect key theft to be, on average, detected faster than that.


Use elliptic curves certificate only if client support them

ECDSA certificates can only be used together with the *_ECDSA_* ciphers, i.e. ciphers like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256. The client sends the list of supported ciphers within the  ClientHello initiating the TLS handshake, so it is in theory possible for a server to decide based on these ciphers which certificate to send.

In practice support for this feature varies, but there is support in Apache 2.4 and support was added to nginx in version 1.11.0. In both cases you need at OpenSSL with at least version 1.0.2.


How can I be sure my Keepass client is secure?

How do you know how to trust any given KeePass implementation? The same ways you know how to trust any software. For me, these are factors I consider:

Open Source

All of the major ports are open.
Probably avoid random Windows Store apps without source available.

Audited by a 3rd party

AFAIK, only the official version has this. I could be wrong.

Active, transparent, development

The official version has active development, but it's pretty opaque.
KeePassX, if I understand correctly, is no longer very active.
Several of the Android and iOS apps seem abandoned.
KeePassXC and KeeWeb are both active and transparent.

Active community

I think all the big ones on a computer have this.
Smartphone apps: hard to say.

Location: depending on where you are located, knowing whether the software is mostly developed in Germany vs. Russia vs. the United States of America may make a difference in your trust.

KeePass itself is developed in Germany
I don't know about any of the others. I know I've looked up the Android apps I've used and the browser extensions but don't remember them.

Developer: is it only one person (who could be compromised), a community (who can police other members as needed), or a company (who can be held liable by others)?

Honestly I think KeePassXC does better in this area.
Official KeePass has only a single maintainer, and I think KeeWeb as well.
I think all the smartphone apps have only a single maintainer.

Popularity: how likely is it that a compromise would be noticed by someone and reported on by tech news?

KeePass itself would definitely be noticed and reported.
KeePassXC, by virtue of being a community project, stands a decent chance in my opinion as well.
I'm unsure about KeeWeb. As far as I know it sees much less use.
For smartphone apps, those mentioned specifically in the KeePass forums on a regular basis are very popular, but probably less likely to be noticed in the tech news sites.


How to calculate brute forcing times/feasibility for remote attacks to include parallelism?

In the real world, the main bottleneck would be the number of connections. Most server implementations, especially webservers, rate-limit this, not just for security reasons (to combat your exact scenario), but also for reasons of fair resource sharing and to throttle runaway clients.

Even if they don't throttle it, a server can only handle a limited number of concurrent connections.

For example, the default configuration for apache2 is set to 150 concurrent connections. That is the hard limit for an attacker, and under realistic circumstances, at least a few of those connections will be busy handling legitimate users.

So the proper answer for n depends on your server implementation first, and other factors second. For a simple scenario like yours, it is trivial to write a client that can saturate the server with requests, the client will not be the bottleneck for any halfway competent attacker, the server will be.


Standard behavior is just to store and/or transmit the IV along with the ciphertext, often prepended or appended to the data. When decrypting, you read the first (or last) N bytes - where N is the size of your IV - and then decrypt just the rest of the data.

There exist crypto libraries to do this directly, so that you don't even have to worry about the IV; the library generates a suitable one automatically for every new plaintext, attaches it to the returned ciphertext, and accepts the combined IV + ciphertext bundle as input to its decrypt function. If you're at the point of asking a question like this, it would be a good idea for you to try to use a really user-friendly library, such as LibHydrogen, which has a very simple but secure API for symmetric encryption. Note that it covers not only encrypting and decrypting with a random IV (called a "nonce" in the documentation), it also performs authenticated encryption such that an attacker cannot tamper with the ciphertext and leave it in a decryptable state.


Question about the public key in the CSR

... or is it actually derived from the private key which was generated?

You can get the public key from the file which contains the private key since all information are in this file. See Can I get a public key from an RSA private key? for more information.

  ... Now, when I import the certificate in the server, I get a public key mismatch. What could be the reason?

My guess is that you've something messed up, i.e. did not use the same private key for the server as you've used when generating the CSR. There might be other reasons like CA not using the given key but creating a new key. But, given that the exact details are not known how you've created the CSR, how you've got your certificate and how you configured the server it is all speculation.


Need assistance diagnosing hacked website

Steps to take in an attack like this:

In this particular case, it is important to cease serving the site, so firewalling it off would be appropriate -- either at a gateway device or by pulling the plug.
Next you would need to image everything you can. Some data can only be obtained live from the machine. I found a decent Windows-focused guide for you from CERT.
From there you need to take steps to identify how you were compromised and prevent it from happening again.
When you've discovered the necessary steps to secure the machine, use a new image.

The symptoms of this attack are that something has managed to alter the data being served by your website. They may be limited to just the files being served up by the site or they may have compromised the entire system.

You'll have to spend your time comparing good data to the damaged data. Hashing all the files between the directories is a handy way to start.

Beyond that, I think you've got a lot of time and learning ahead of you, or an outsourced forensics / malware / general security expert who is looking forward to you as a client.


OCLint works on Linux and OSX. It doesn't focus on security, but integrates with Clang, a static code analyser to do style and security at the same time. Of course, if you don't care about style you can just use Clang to begin with! But if your code is tidy and readable, your security reviews will be a little less painful.

Agnito also scans objective-C, and it costs $0, just like the other tools.

(I am not affiliated with these projects.)


java script in link href="javascript:alert(1)"

I don't think this method would be safe from XSS. This type of vulnerability sounds like a typical case of Reflected XSS. If you would escape the href tag with some " you can enter a XSS code. Your link would look like this if you enter foo.at"><script>alert(81)</script>"page=1 into the input field ->

<a href="http://foo.at"><script>alert(81)</script>"page=1">google </a>

I would suggest to use a filter on the website which converts all special chars to an other format. Like htmlspecialchars in php.


Yes, is possible.

BeEF usually works with these ports:

2000
6789
3000

Two of them are only used to connect locally. So you only must open port 3000 tcp which is used for "hooking" the victims and to access to the ui control panel. You can change this port in your config changing port: "3000" to other but usually is not necessary.

If you open port 3000 is enough to access to control panel and hooking. You can restrict the hooking networks and the access to the ui control panel modifying on config these lines:

permitted_hooking_subnet: "0.0.0.0/0"

and

permitted_ui_subnet: "0.0.0.0/0"

Another good practice is to change the default pass "beef" to other to avoid somebody can enter to your control panel. This can be done changing this in config file: passwd: "yourpass" under credentials section.

Remember to load your custom config using -c argument. Example: cd /path/where/beef/is && ./beef -c /path/to/your/configfile. Sometimes on distros like Kali Linux, if you check "/usr/bin/beef-xss", there is a script inside, so you can't launch custom configs using beef-xss -c /path/to/configfile that's because is better to locate where is beef installed, enter to the directory and launch it using ./beef for some reason it doesn't work using absolute paths in this way /path/to/beef -c /path/to/configfile that's because the first example I put is the good. Some usual paths where beef executable file is installed depending of the distro are:

/usr/share/beef/ -> on BlackArch
/usr/share/beef-xss/ -> on Kali
/opt/beef/ -> on Wifislax

Then you must be able to force the victims to load the "evil" js putting the "hook.js" in anyweb page loaded by clients or however... that's another story.

Good luck!


How to add wildcards to snort rule ip address?

Snort doesn't support wildcards or regular expressions on IP addresses/ranges. It does support CIDR notation for IP ranges, a few pre-configured variables in snort.conf like $HOME_NET and similar, and a ! for IP or IP range negation (edit: Oh, and of course any, but not !any).

What you could do however is to define a new ipvar variable, fill it with the list of IPs that match your requirements, and then refer to it in the rules definition to simplify things and avoid adding 256 individual rules:

ipvar ENDS_WITH_A_NINE [192.168.0.9,192.168.1.9,192.168.2.9,192.168.3.9,192.168.4.9, ... ]
alert tcp $ENDS_WITH_A_NINE any -> any any (msg:"Last octet of 9 detected!"; sid:9;)

This way, it will be a lot easier to maintain your Snort rules. I realize it doesn't look elegant, but it shouldn't take you longer than a few minutes to copy all the 256 possible IP addresses in the variable list, and beats creating all 256 rules, then later realizing you need to change something in them.

Anyway, hope this helps! ;)


How is OTR messaging with Socialist Millionaire Protocol (SMP) protected from Man In The Middle?

As far as I understand, SMP does not protect against MitM per se. The paper's authors clearly state,

  Suppose that Alice and Bob are chatting online using OTR and decide to
  run the SMP, but have not previously selected a secret and possess no
  channel more secure than their current conversation. They can still
  select an appropriate secret in this case, but they will be more
  vulnerable to attack.

The SMP protocol is used to compare that shared secret without needing to send it in the clear, but the shared secret must already exist.

Otherwise, to Alice's eyes, there would be no difference between Bob and Joe. For the same reason, Alice and Joe would be identical to Bob's eyes. Which would lead to a perfect man-in-the-middle scenario.


Are GUID visible when compiling a .NET project?

No. EDIT: Actually, possibly. See below.

The compiler really only cares about the source files. If you want a GUID to be in the assembly you need to code it in. Thats how for instance the COM interop stuff works -- you decorate the assembly in code with an attribute that contains the GUID.

However, if a GUID is hardcoded into the source for something like COM, and the GUID was generated on the same machine, using version 1, then you could potentially track down the machine it was coded on. See here: http://blogs.msdn.com/b/ericlippert/archive/2012/05/07/guid-guide-part-three.aspx

EDIT: It turns out I'm slightly wrong. Its an implementation detail in one of the compilers, but in the current release of the compiler a GUID is used to distinguish build versions, e.g. every time you hit F5, so all builds regardless of code-change are unique per computer.


... does it prevent my ISP or network admin from seeing/logging the sites I connect to similar to how HTTPS prevents them from seeing passwords I enter?

DNS over HTTPS will prevent your ISP/admin to sniff and modify DNS requests and only DNS requests. They will still be able to get information on which sites you visit from inspecting other traffic you produce, i.e. from HTTP headers in HTTP requests, from the domain information in the TLS handshake in HTTPS, by checking which IP address you connect to etc.

  ... Does it allow the bypassing of firewalls similar to that of a VPN?

It allows to bypass DNS based blocking which is often to block sites at the ISP level since it is the easiest and cheapest thing to do for the ISP. But other inspection and blocking methods continue to exist, but these are more costly to implement.

  ...  It what ways does it differ from a VPN?

A VPN encrypts everything, DoH only the DNS traffic (see first item in this answer). A VPN thus offers more protection against sniffing or modification by the ISP.


How to solve this double master password dilema with dashlane?

The goal of a password manager is indeed to reduce the memory requirements needed to use lots of strong, unique passwords or passphrases.  But they don't completely eliminate all memory burden, as you've noted.  There will always be some passwords/passphrases that you have to commit to memory.  Password managers just help you reduce that to a manageable number.

So yes, you should have a separate email password and memorize it if you need to log in on a system where you won't have access to your password manager database.  That's true of any similar situation, regardless of the behavior of a particular password manager product.

Alternatively you can write your email password down on a note that you keep in your wallet or other private place, if you are willing to accept the threat of someone finding it there and figuring out what it is.

I would still keep a record of your email password in the password manager just as a failsafe since you could still access it from a trusted computer in the case of a memory lapse (or losing your wallet).


Is it possible to generate valid track 1 and track 2 data from basic CC info?

Explicitly not.

The whole1 concept of magstripe data on the card is to prove that the card was present at the time of the transaction.  If you were able to reconstruct it without the card, that would defeat the purpose. Likewise, that's why PCI rules require you to never store the full swipe data (so you can't replay it later). 2

If you look at what's in the swipe, you'll see that both the Service Code and the Discretionary Data fields are not printed on the card anywhere.  Service codes are standardized, but there's no way to know ahead of time (i.e. without swiping) what it will be. Discretionary data is unique to each issuing bank, but usually contains information such as the CVV1 (which is not what's printed on the card), an encrypted PIN (for ATM use), and other distinguishing data.  The discretionary data is also different between the two tracks.

Basically, there is no way for anyone except the issuing bank to know whether correctly-formatted swipe data is actually valid or not, but there's no way to fake it to the bank, either.

1: This isn't quite true: It's also for speed and automation.

2: The rules also prohibit storing the CVV.


A customer support of where my company host a VPS on asked me login detail, is this standard procedure?

No, this is not normal at all.
If you need to give them access, create a new account for them that exists only for as long as they need access. Only give them as much access as they need.
But they should have resource monitoring from the VPS side and shouldn't need local access to the server.


This is the only PHP security course that I've heard of. I know of the author (Johannes Ullrich) and he's excellent but then he's not always the instructor. Here's a complete list of SANS web app sec courses since that's the topic you're essentially asking about.

Regarding CISSP, I decided not to go for it, it just wasn't for me. I felt it was too general and too high-level so I went and did a few SANS courses and certifications. SANS courses are much more technical and well-respected, though they do seem more popular in the US than say, Europe. I've heard mixed reports about CISSP but I'm not in a position to comment further.

There's loads of courses and certs out there so you need to have think about what you want to do, what technology you'd like to work with etc and go from there.

I'm not a huge fan of vendor courses/certifications so try to stick to something independent and that's useful across multiple jobs/industries.


How can I get more spam for my honeypot?

Spammers will "scrape" the internet for email addresses and use programs to collect millions of addresses. Or just download them.
If you want your email address to be picked up by spammers, you need to expose your email in multiple different places. The common targets for spammers are social media sites and places like pastebin.


What happens if someone steals one of my additional domain controllers

Your domain controller needs to be able to authenticate users. So it needs to be able to verify user/password combinations. Thus it needs to store password information.

This is not stored in plain text, but worst case people will eventually crack those.
Having an DC get stolen is therefor a bad thing.

The DC will also contains lots of other information, such as computer IDs, security groups, membership to security groups, DL list, ... All things which you might not intend to share but not as bad as the [domain admin] passwords.


Is it possible to identify mobile phone user with voice recognition

Well it is probably true and trivial to fake. You can find speech engines around, and if you use such a speech engine, it will not be possible to identify the human being that prepared the text.

Worse, it is easy to get words and/or partial sentences from public people from radio, or internet. Simple audio file processing could then make them say more or less anything. And you soon fall in the same problem of identifying gangsters wearing masks from facial recognition...


how does the 'Same origin policy' prevent XSS attacks

It doesn't.

The SOP works when there is no XSS vulnerability.

It ensures that evil.com cannot read data with your authentication from eg facebook.com. This holds true as long as facebook.com doesn't introduce it's own vulnerability which allows bypassing of the SOP.

And that is where XSS comes into play. It essentially allows bypassing of the SOP, because now an attacker can execute their script from the same origin as the application (eg facebook.com).


What are the privacy implications of using Yubico OTP with YubiCloud?

Yubico will not know, which users are logged in. The yubikey only sends a serial number within the otp value. They use this serial number to map the AES key.

So it is not anonymous but pseudonymous. If they ever would map the identifier/serial number to the user, they know it.

But (tin foil hat mode)
yubico may know which serial number they sold to you. So yubico knows, that someone of your company is logging in. They also might know this from the requesting IP address.
Then they could decide to say aye or nay, not depending on the real presence of the yubikey but depending on if the FBI wants to login or not ;-)
(tin foil hat mode end)

If you worry about this you can use privacyIDEA running on premise to validate all your OTP devices (in HA mode).

PAM is a mighty stack. You can configure everything you wish to. So you could configure a local authentication instance and fallthrough to the cloud service. But as mentioned above - you can also configure your local service in HA.


How can I tell if a keyboard for android is safe?

I am not handling valuable information in my phone, other than online account passwords including banking passwords, etc.

Aren't these passwords valuable enough? They are the key to your banking accounts and online accounts!

  How can I assess the risks presented buy any particular keyboard?

For an average or normal smartphone user, there's nothing much that can be done about it. Security experts can sniff the packets and try to see if anything sensitive is being passed on to the servers.

  In terms of key-logging, am I more or less OK if a keyboard does not require network access? If so, can the keyboard gain network access in other ways than asking directly for the network access privilege?

It should be okay, as long as you trust the application. Even apps without network access can wreak havoc on the phone if they contain malware. It's better if you go with a trusted keyboard app from trustable sources like Google Play.

Regarding the permissions being asked by SwiftKey keyboard, they've explained the purpose of each permission on this link. Although there's no guarantee that the information gathered is used only for the specified purposes.

My suggestion would be to go with a trusted keyboard app like Gboard or Swiftkey.


If you are stepping through one instruction at a time, and the segfault occurs immediately upon jumping (and not when hitting some potentially broken shellcode at the end of the NOP sled, which could also cause a segfault), and you are certain that the address is correct, points to valid memory and that your NOP sled itself isn't broken, then yes it seems plausible that the segfault is being caused by DEP.

However, the other things I list above are more likely in my opinion, and there are lots of other reasons why a segfault might pop up.

Just so we're certain you've got everything right in gdb;

You should have a breakpoint just before the return instruction you have corrupted. You can do this via the disas and break commands.

Once the program hits your breakpoint, you want to check the lay of the land. Check eip with the info r command. And have a look at your stack using things like x/40x $esp. You should be able to see your nop sled, shellcode, and return address repeatedly afterwards. Another note that just came to mind; the return address has to be aligned properly, usually this means putting 1-3 nops after your shellcode to shove it into place.

If all looks well, then it's time to run a step. If info r now reports that eip contains an address that is on your nop sled - check this with a x %eip, you should see 0x90909090. Then hit step again. If at this point you get a segfault, then yes (to answer your original question :P) you have DEP turned on IMHO.

Sorry if that was all stuff you already knew, it's just vital to check everything several times when you're playing with memory exploits.


Difference Between Binary Exploitation and Reverse Engineering?

Rather that cite definitions of the terms I'd like to give my personal view of what these things are.

Reverse Engineering is the process of taking an output and and figuring out what the input was. It also means tracing the steps that a piece of information took from it being inputted up until it is outputted. Think of this as figuring out things work without having the source but a level of abstraction just above the machine. When it comes to software, reverse engineering tends to be the process of debugging the running code of an application in assembly as it runs. Watching it run, following the process it takes, allows you to trace the steps and reassemble them yourself into something meaningful you can use yourself.

Binary exploitation is the process of abusing subtle (or perhaps not-so-subtle) flaws in software to make an application performs functions that it wasn't design to perform. While it's not impossible to exploit flaws in binaries without doing reverse engineering, I would argue that almost all binary exploitation exercises begin with reverse engineering to understand how the application works and to help identify the flaws.


Update: A full specification PDF for version 1.0.0 of the LUKS2 on-disk format can now be found in docs/on-disk-format-luks2.pdf. (It's a permalink, so check the master for updated versions.)

It's in docs/LUKS2-format.txt.

They have a comment saying:

Note: these are temporary documentation notes only.
The more formal definition will be published later.

So a full comprehensive documentation beyond this file doesn't seem to be currently available.


The "misbehaving" pcap has a capture for HTTP proxy traffic on port 443, i.e. a HTTPS traffic prefixed by a HTTP CONNECT request and response. Port 443 is reserved for direct HTTPS though and not for proxied HTTPS.

It looks like Wireshark somehow insists that it should be either direct HTTPS on this port (which is how the port is commonly used) or that it should have nothing to do with SSL at all. Thus it will detect the HTTP proxy request and response but will then refuse to decode the rest as SSL even if explicitly specified in the settings. I did not find a way to change this behavior.

If one rewrites port 443 in the pcap to something else (like 4433) using tcprewrite the problem magically vanishes and it will happily show the SSL protocol details. Thus, it is all because of some strange behavior of Wireshark and is not a problem of the data itself.


So that got me curious. How can MailChimp automatically authenticate
  emails without accessing my servers to modify my domain's DNS records?

As far as I can see... they can't.

From their own setup instructions:

  To set up custom DKIM, you must create or edit two files, known as
  "records," through your hosting provider, domain registrar, or DNS
  provider.

And from the very page you referenced:

  Some methods (SPF, SenderID) simply require a file on your server that
  can be cross-referenced by a receiver.

My guess is that either:

They're talking about sending via one of their own domains rather than your own
They mean it as an aspiration related to their participation in the  "Authentication and Online Trust Alliance" (which they link to underneath) rather than something which is true today


Why ask for username/password after a successful password reset?

It's safer to avoid handing out a session token on a successful reset. It also helps reinforce the new password to the user or makes the user's password manager more likely to detect the update. The part of the code that handles locked out users should be totally independent of the part that authenticates them.


Certificate SAN Disclosure. How harmful can it be?

First, it is perfectly normal for content delivery networks to have such certificates. And given the IP address this looks like Amazon AWS, possible their CloudFront service which serves as a TLS termination point and load balancer which then forwards the traffic to the appropriate system. This is actually typical behavior which you will also see at Cloudflare CDN. Therefore I don't think that this was a mistake.

  This is information leakage, it discloses websites that aren't advertised on search engines.

I think that these sites have explicitly configured HTTPS access so that they get included in the certificate.

  The virtual web-servers all share the same VM The virtual web-servers all use the same certificate. therefore if the private key can be leaked/disclosed by one web server using an insecure SSL/TLS protocol.

This certificate is probably used at a load balancer which then forwards the requests to different sites which in case of Amazon AWS are probably each in their own VM.

  Each customer should be concerned as this is potentially vulnerable to Meldown/Spectre ?

No. Sharing the same TLS termination endpoint should not cause such problems.

  Also, If one of this website was to be compromised (Injection or XSS). Does it compromise other websites ?

XSS is not an attack against the server. Other injections like SQL injection can be. But given that these are probably independent sites running in their own VM a compromise of one VM does not compromise the other one.

  And finally, Should I have any concerns if my company was hosting a website on this server ?

No.


How to "break" remote access on Windows and rooted Android?

I don't see much of a difference with your previous question How to close or block remote access backdoors? except that it now a bit more focused by asking only for Windows and Android.
It looks like you are not asking about disabling explicitly implemented remote access functionality but anything which might allow an attacker to allow remote access. Since this might also include bugs in the firmware and drivers the only way to disable remote access is to disable any network connectivity at all, i.e. disable network interfaces and/or put the device in some Faraday cage or similar. This includes everything which might be reachable by the hacker you envision, i.e. Ethernet, WiFi, Bluetooth, USB based networking and maybe even NFC.
Of course, this makes the devices kind of unusable for most modern use cases. Given that it may be questionable if it makes even sense to harden an existing device/OS this way, or if is better to use some more specialized device with a smaller attacker surface for this specific use case instead.


Stack location range on linux for user process

Yes, there is a range, and you can determine that range trivially for any running process. Read a given process' /proc/<pid>/maps to see its memory layout, as well as the type of memory in each address range. This is described in proc(5). A sample from an embedded device:

root@UP-7197:~# cat /proc/self/maps
00400000-0044b000 r-xp 00000000 1f:02 944        /bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:02 944        /bin/busybox
77450000-77472000 r-xp 00000000 1f:02 802        /lib/libgcc_s.so.1
77472000-77473000 rw-p 00012000 1f:02 802        /lib/libgcc_s.so.1
77474000-77506000 r-xp 00000000 1f:02 891        /lib/libc.so
77513000-77514000 r--p 00000000 00:00 0          [vvar]
77514000-77515000 r-xp 00000000 00:00 0          [vdso]
77515000-77517000 rw-p 00091000 1f:02 891        /lib/libc.so
77517000-77519000 rwxp 00000000 00:00 0
7fc55000-7fc76000 rw-p 00000000 00:00 0          [stack]

The syntax is explained over at Stack Overflow.


Hijacked Aol Email Account - Lack of security?

Isn't it some kind of security lack that some guy is able to connect to your email account, and is able to change your alternative email without sending some link to it before confirming the change ?

Yes. Some systems delay the change of secondary email from being effective in order to allow a legitimate owner to recover it, but most systems simply allow it and instead rely on detecting after the fact that it was indeed stolen in order to reassign it.

It is often painful to get them to do that. You would expect them to have a log stating that the password, secret questions and recovery email were all changed 2 hours ago, and that you have access to the secondary email (eg. by providing the timestamp they sent it).

Maybe the user scripts they are using are simply not prepared for this eventuality, or their first tier support is unable to recognise a compromised account. See the article of the "Epic Hacking" suffered by Mat Honan for a number of failures by Apple customer support.

  (And by the way, if someone has a solution to offer, I'll take it happily !)

Try to get someone brighter than 'Alex' to handle your issue. Request your call to be escalated.
Report the account theft to your local police.

The existence of a police report should increase your odds of being taken seriously.
The police may request AOL the connection info from which the account was stolen (probably a dead end, though).

and of course the sooner you act, it's more likely they will believe you, and harder that their logs "already got deleted".


Should I implement my own local password hash?

What you describe is one of the two main methods used by "password vaults" products. Such products try to make it easier for you (the human user) to "remember" site-specific passwords, while still maintaining the important property, that is the specificity of passwords: one password for each site, so that a breach on one site does not endanger your accounts on other sites.

The two main methods are:

Try to "derive" (through hash functions or similar construct) a site-specific password from a master password; the site name is then used as extra parameter, to make sure that each site get its own password.
Generate random passwords for each site, and store them locally (on the client), encrypted with a "master password".

In both cases, you need client-side software, because there is no known method to achieve the one-wayness required for proper specificity with only human brain capabilities (see this previous question). Such software can be a local application, some script, a browser extension...

Your proposal relates to the "type 1" method (derivation from the master password). The usual hope is that the "type 1" method may allow for dispensing with local storage. Unfortunately, this fails on two accounts:

As you have noticed, password rules mandated by various sites are incompatible with each other, so you can not produce passwords which can fit all possible sites. Therefore, something in your system must remember the rules for each specific site, so that the site password can be recomputed properly.
Some sites mandate password changes at more or less regular intervals. A no-storage password derivation cannot cope with a password change.

"Type 1" password vaults still have value, in that the required local storage needs not be confidential, since it includes nothing which depends on the master password (it does include information about all the sites on which you have accounts, though, and that may be a privacy issue). On the other hand, each site-specific password may be used for an offline dictionary attack on your master password, which can be a problem.

"Type 2" password vaults are more flexible and are thus more common (e.g. KeePass). Some of them couple with a centralized storage (see 1Password) so that you may have access to your passwords from all your devices. A really good point of "type 2" vaults is that the site-specific passwords, being randomly generated, cannot (in a strong mathematical sense) leak information about your master password or passwords for other sites.


I wont go through vulnerabilities present, but I can walk you through my process/thinking.

static analysis tools - start with the obvious and have some tools take a look at it, a couple of options include Visual Code Grepper and Cppcheck
Next we look at things manually, start with functions that are dangerous, these tend to be string and memory manipulation functions.  Follow the code backwards up the call stack to see where they get their data from, checking if that data has been properly validated.  If not, then that is likely to be another vulnerability.
Next, start at all your program inputs, this include program arguments, anywhere where user input has been entered, network reads etc. etc.  Then walk through the code to ensure that all inputted data has been properly validated.  Again if not, then this is likely to be another source of vulnerabilties
Finally (there may be more steps, but this'll get the bulk of them) look for language or framework idiosyncrasies.  Do you have API calls that have the wrong arguments e.g. a realloc where the resultant pointer is the one used in the call.  Is there a correct sequence of API calls required to set something up (crypto falls into this category)

That's more or less what I do, though I have a step 0 which is to read the code top to bottom, just to get a feel for it, it's odd, but you can spot things just because they look funny


The best practice to manage the private / secret keys in memory is to use a memory physically out of reach of attackers, such as a HSM, Smart Card, Trusted Platform Module, or Secure Element.

Problem is, that's hardware, and on modern machines (servers, cloud, PCs, mobile), trusted hardware is not easily usable (though often present; in particular I see some renewed interest for TPM 2.0 in server/cloud).

Software-only options are a compromise. A reasonable one it to

Trust the hardware + OS to keep at least memory content of a process private, and keep private / secret keys is a separate process doing the crypto, exchanging messages with the process using the crypto.
AND stick to algorithms that have inherent protection against side-channel / cross-process leaks, because attacks on this front are aplenty. Libsodium is a good choice from this standpoint.

The combination at least makes a leak of a private / secret key unlikely to result from vulnerabilities in the process using the crypto (due to practically inevitable bugs in the unmanageably complex software stack involved in a typical application). A drawback is that access to the process doing the crypto must be managed securely (e.g. thru access rights enforced by the OS), which adds complexity.

One way to see so-called "enclaves" is as a standardized implementation of that design principle.

My opinion on the subject of multiplying the secret versus using pointers to a centralized area is that it is secondary from a security standpoint, compared to process isolation. I tend to prefer pointers, not so much because it is slightly more efficient, but because it saves from the hassle of having to zero copies no longer in use in order to follow guidelines requiring that. I regard such zeroing as technically non-essential (again, compared to process isolation); but like using e > 216 in RSA, it's something to bow at.


The request parameter is encoded with Windows Codepage 1251 and contains an apparently harmless error message in Russian:

  используем прокси 85.17.122.209:6188; не нашлось формы для отправки; Result: GET-таймаутов 1; не нашлось формы для отправки;

Roughly translated to English, the message reads:

  using proxy 85.17.122.209:6188; there were no forms to be sent; Result: GET-timeout 1; there were no forms to be sent;

It surely does not look as if someone is trying to hack you. I would rather assume that something is trying to report an error and due to misconfiguration is calling your server instead of whatever is supposed to track or handle the problem.


netdiscover forges ARP packets, and one of the fields of an ARP packet is the source address. To ensure that the packet appears to be from a host on the current targeted subnet, netdiscover chooses an source address ending in 67 (not really sure why 67 was chosen). It's not actually changing the address of your adapter, it's just the content of the crafted packet.

The reason you are able to see the reply is because netdiscover is listening for responses, and your actual MAC address is what other devices will reply to. Here, the IP address is fairly irrelevant.


Is using Kali Linux in corporate enviroment safe?

Kali is a community-built distro full of security tools from both organisations and individuals. It is not designed to be used as a day-to-day operating system. It's a quick-start, throw-away distro for security testing.

Metasploit and Kali Linux are entirely different things. In fact, Metasploit is installed on Kali by default. I suggest you read up on what they do and how, to better understand their function.

As far as I know, Kali has never had any explicit backdoors. The tools themselves, like any other software, have had security issues along the way. This is normal.

If you want reassurance, I work as a pentester, and pretty much everyone on my team has a Kali VM installed on their testing system. The same goes for every pentester I know in other companies.


Sanitizing input for parameterized queries

No, it's not necessary. But please, read on.

Input sanitization is a horrible term that pretends you can wave a magic wand at data and make it "safe data". The problem is that the definition of "safe" changes when the data is interpreted by different pieces of software.

Data that may be safe to be embedded in an SQL query may not be safe for embedding in HTML. Or JSON. Or shell commands. Or CSV. And stripping (or outright rejecting) values so that they are safe for embedding in all those contexts (and many others) is too restrictive.

So what should we do? Make sure the data is never in a position to do harm.

The best way to achieve this is to avoid interpretation of the data in the first place. Parametrized SQL queries is an excellent example of this; the parameters are never interpreted as SQL, they're simply put in the database as, well, data.

For many other situations, the data still needs to be embedded in other formats, say, HTML. In that case, the data should be escaped for that particular language at the moment it's embedded. So, to prevent XSS, data is HTML-escaped at view time. Not at input time. The same applies to other embedding situations.

So, should we just pass anything we get straight to the database?

Maybe. It depends.

There are definitely things you can check about user input, but this is highly context-dependent. Because sanitization is ill-defined and mis-used, I prefer to call this validation.

For example, if some field is an supposed to be an integer, you can certainly validate this field to ensure it contains an integer (or maybe NULL).
You can certainly do some validation on email fields (although some people argue there's not much you can do besides checking for the presence of a @, and they have a good point).
You can require comments to have a minimum and maximum length.
You should probably verify that any string contains only valid characters for its encoding (e.g., no invalid UTF-8 sequences).
You could restrict a username to certain characters, if that makes sense for your userbase.
A minimum length for passwords is, of course, incredibly common.

As you can see, these checks are very context-dependent. And all of them are to help increase the odds you end up with data that makes sense. They are not to protect your application from malicious input (SQL injection, XSS, command injection, etc), because this is not the place to do that.

Users should be free to type '; DROP TABLE users; -- without their post being rejected or mangled to \'; DROP TABLE users; --. Note that I'm able to include such "malicious" content on sec.SE!

So, to answer your original question:

  ... is it still necessary and/or security-relevant to somehow sanitize input?

No, it is not. But please do properly escape the data where needed before outputting it. And consider validations, where applicable.

  I think of benign, but not-so-well-engineered 3rd party tools (maybe self-written scripts by the admin, or some fancy CrystalReports made by a non-technician) trying to consume unsanitized data from our database.

Then escape or filter the data before outputting to those tools, but don't mangle data in your database.

But really, those scripts should be fixed, or rewritten with security in mind.

  (MySQL seems to have problems with Emojis)

Little off-topic, but have a look at the utfmb4 charset for MySQL ;)


802.1x certificate authentication, private key?

is the private key stored on the device that is wishing to access a given resource network ...

For authentication using public-key cryptography as done in 802.1x or in TLS certificates the authenticating party needs to proof ownership of the private key. This is done by doing cryptographic operations using this private key, typically by signing some value given by the peer or derived from a value given by the peer.

Such cryptographic operations can be done by some software running inside the clients operating system if the private key is accessible to the system, i.e. typically stored on the file system. But it could also be done by some special hardware integrated or associated with the system, like a smart card, TPM, HSM or similar.  Such operations could also be done on a remote system like in Cloudflare Keyless SSL.


Where to store IV and salt when doing clientside encryption with no server

In every protocol I've seen, the IV and/or salt is not considered secret, and is stored with the ciphertext. It is usually important to use a unique IV/salt for each message, though. (It is often not necessary for them to be unpredictable— just not reused.) However, each mode's requirements might be a little different.


Does certutil -delkey actually delete the certificate and private key?

certutil is one of the less-well-documented commands I know of. However, both by considering the existence of the -delstore command ("Delete certificate from store") and considering what a key container is probably doing, my best guess is that the command deleted the private key storage (and, presumably, any private keys it contained) but did not delete the corresponding certificate(s).
Does the certificate in question have an associated private key known to the system? You can find this at the bottom of the text output, somewhat indirectly - it'll say "Cannot find the certificate and private key for decryption" or similar if not - or you can use the certmgr.msc graphical tool to view installed certificates and ones with a private key will display this on their icon, plus have the text "You have a private key that corresponds to this certificate" in the General tab of the certificate info window. If it didn't now, did it have one before?


Why does ATMs have a green plastic thing in front of card reader?

There has been a constant rise in ATM frauds and scams most specifically ATM skimming effecting consumers secured transactions. In order to combat ATM skimming ATM machine manufacturers are manufacturing ATM with anti skimming technologies which appear as a green casing that protrudes from the card insertion slot. Many a times there are chances that ATM thefts might occur by simply mirroring these anti skimming parts, for which one should always remain careful. - What is the green thing on the card reader at ATMs?

But ATM MagStripe skimmers still exist!

Green Skimmers Skimming Green

Despite the flawed anti-skimming system, it's worth realising that the credit/debit card's magnetic stripe is inserted perpendicular (longways) allows for easy skimming.

Being flush would also allow for skimming devices to be connected, only much easier.

  ATM manufacturer Diebold claims to have found the answer to skimming fraud with a new reader that requires users to insert their card sideways on to prevent the copying of data stored on the magnetic stripe. - Diebold takes 90-degree shift to counter ATM skimming

With all this knowledge, why not discontinue magnetic stripe and end the raising fraud pandemic?

  Replacing the 15 million payment terminals in the United States would cost roughly $6.75 billion, according to Javelin’s estimates. - Why Is the U.S. Determined to Have the Least-Secure Credit Cards in the World?

Alright, so it's actually more economical for banks to have an annual reserve to pay fraud costs than overhauling the current infrastructure.

  Even if the US merchants had surpassed the 75% adoption stage, however, it would still be prudent to include a magnetic stripe on the back of chip cards to ensure that no payment transaction will be lost, within or outside of the country, as a result of the lack of an updated merchant payment system. Why do credit cards with a smart chip still have a magnetic strip on the back of them?


Why can't you use the same password for every site, if they are hashed on the site?

Passwords may be stored as a hash in the database, but there are so many ways that this simple process can go wrong. And once one of your passwords is known, then all the rest of your accounts are at risk.
Consider the very simple case where you enter the password into the username field. Now your password is exposed in clear text in every server log for that site. And you can't go back.
Consider also a website that made a small change to their login process, but there was an error in their code, and all passwords entered were also in a plaintext file that the developers forgot to disable (this actually happened to a major site).
Once one password that you've used gets exposed, for whatever reason, then you have to go to all your accounts that used that password and update the password on them all, else you risk that account.
Instead of re-using passwords, use a password manager that can take all the guess-work and memorization out of the equation.


An entry like that is probably a speaking point for the presenter. I'd put something like that there if I knew of a case where a multi-level security system that related to information classification had a notable failure... in Australia.

But it's not a well-known name for any failure, and I've tried a few variations of http://www.google.com/search?q=%22australian+failure%22+security with no apparent hope of getting anything other than the slides in question.

Given the location in the presentation and the topic of that section, I'd say it's not a well-known vulnerability. It's probably a specific implementation failure example. You just don't really run into much that does that kind of classified handling outside of places that play with governments. Security there is a different world.


Should repositories with server-code and client-code be separate?

Yes, these should generally be split.

They might together form one solution, but the code itself is logically separate. As such, people with access to one repository don't necessarily need access to the other.

What are the risks?

Selling vulnerabilities to hackers is a possibility, but those hackers can also just find the same vulnerabilities in your code. A much greater risk is to sell the code itself to a competitor, or use it to build a competing product.

While I am not accusing you contractors of doing that - they may very well be honest people doing honest work - there have been reports of contractors doing exactly that. They spent their time analyzing your product, even having their questions answered by staff, and a year later came out with a competing product. While it could not be proven that they stole any code, it is too much of a coincidence to be a coincidence.

How to split the code?

Depending on your version control system being used, this may or may not be an easy task. If you use Git, for example, it's not as simple as just duplicating the repository and deleting one half of each. Git keeps all the old files in its history, so a contractor with access to a local copy of your "client-only" repository could still happily browse the server data up until the point of the split (which may be enough to be malicious). Newer contractors, who then check out the new "client-only" repository, would still be able to get access to the server data.

The "simplest" way would be to completely erase the old repository and re-build two repositories with their respective commit history. This can take anywhere between an hour and a decade of work, depending on how large the repository is.

There may be automated tools available, or you may be able to write your own script for that too. I was never in this situation, so I don't have any hands-on experience with it.

Of course, this would still leave the contractor with local copies of your old code, but this code must already be considered compromised if it ended up on their machines. But at least it would stop future contractors from getting access to it.


Don't do this. Add the expiry to the database, and check whether the token is still valid. If you add it to the URL, you are inviting people to modify it.
Why are you sending a password out? The industry best practice is to send a short lived, single use token that takes users to a page that allows for entry of a password and a password confirmation, then sends them to the application login page to use the newly entered password to log in. That way, you avoid ever sending passwords from your server, meaning that only server compromise of some sort will reveal any passwords, whether user or system generated.
There is not really a concept of "the mail client with that email address" - for example, I have an email account which I access from web browsers on various computers, an email client on my personal computer, and an email client on my phone. I also access other addresses with those same clients. The general way to ensure only the intended user can use such links is to keep the validity period as short as possible - an hour or so at most. There may be some users whose email takes longer than that to arrive, but remember that they are actively trying to log in at that point. If you tell them you have sent an email, they will probably go and look for it.


SQL Injection syntax inquiry-commented injections

In short, the syntax after the -- comment marker is part of the original query.  For example, if the query was run without injection but with username "Dean" and password "WinchesterS", then the query would look like this:
SELECT * FROM users WHERE username ='Dean' AND password = 'WinchesterS';

The SQL Injection in this case is:
Dean' OR '1'='1'--

Now, if that is entered as the username field, it extends the username into a SQL OR statement, which will always be true, thus allowing login.  However, the original end to the query is still in place:
' AND password = 'WinchesterS';

In order to avoid a syntax error, the -- comment marker is used to ignore that part of the original query.


How to reverse engineer password from /etc/shadow

A bruteforce attack using JTR shows the password as qwertyuiop.

root@pro5:~/hack# john file.txt
Loaded 1 password hash (crypt, generic crypt(3) [?/32])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:14 40% 1/3 0g/s 67.89p/s 67.89c/s 67.89C/s :99999..DrAdmin
qwertyuiop       (admin)
1g 0:00:01:15 100% 2/3 0.01325g/s 68.11p/s 68.11c/s 68.11C/s samsung..britney
Use the "--show" option to display all of the cracked passwords reliably
Session completed
root@proc5:~/hack#

It cracked the password in less than 5 minutes with my old Pc as it is a weak password. If the password is strong it will take more time to crack it.


Does the "Key Encipherment" key usage make sense when using ECDH P384?

The relevant spec is section 3 of RFC 5480 ("Elliptic Curve Cryptography Subject Public Key Information") which extends RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile").

A key used for ECDSA is used for digitalSignature.

If the key is used for signing things other than certificates and CRLs (and TLS handshakes) then use nonRepudiation, if the key is controlled by hardware device and certificate was issued in a way you can't later claim "it wasn't me". It can have specific legal meaning in some jurisdictions.

A key can be used for keyAgreement (ECDH), but modern TLS uses ephemeral DH to provide forward secrecy, so the key for the certificate is not itself used for ECDH.

It is generally not used for ECIES (encryption), though technically you can do that. It is a best practice to not use the same key for both signatures and encryption, though I am not aware of any vulnerabilities if you do. But generally, if you encrypt backups using a public key, use another key.

Look at the google.com and cloudflare.com ECC certs. They use bare digitalSignature bit in keyUsage. A CA ECC cert uses Digital Signature, Certificate Sign, CRL Sign.


Which algorithm is safest if we exclude AES, Twofish, Serpent and Whirpool?

I won't say that it's overkill, but I will say that I think you need to get a better understanding of cryptography before attempting to secure your data for 100+ years.

Encrypting in a cascade is actually difficult to do correctly. You need each algorithm to be truly cascaded such that it's impossible to determine if one has been successfully broken without breaking all the others. If you use one encryption program and then another one on top of that, an attacker will be able to break each cipher one at a time. A true cascade (as VeraCrypt does) would make it such that an attacker would need to break every cipher at once to know whether or not they have succeeded. Unless you either modify the code of VeraCrypt yourself, or use an alternate utility that allows true cascading, what you're doing is a bad idea.

Let's go over the ciphers you have available. Blowfish, IDEA, CAST5, and 3DES have a 64-bit block size, making them insecure for encrypting large amounts of data. 3DES is further vulnerable to linear and differential cryptanalysis which becomes possible when encrypting very large amounts of data. This leaves only GOST and Camellia. The GOST algorithms have not been extensively analyzed, so I would not trust them for long-term use. This only leaves Camellia, a cipher with a high security margin. I would suggest Camellia.

Now let's go over the hashing algorithms you have. For PBKDF2, an algorithm that iterates a single hash multiple times to slow down brute force attacks, the choice of algorithm doesn't particularly matter. However, let's exclude MD5, SHA-1, and RIPEMD-160 anyway for being old. This leaves us with SHA-256, SHA-512, SHA3-512, and Skein-512. SHA-256 and SHA-512 are both quite secure. The former is, paradoxically, slower than the latter on 64-bit CPUs. They are both good choices. SHA3-512 is based on the Keccak permutation, which has a remarkably high security margin. However, it's designed to be fast in hardware, not software. This means that an attacker with a hardware-accelerated SHA-3 implementation has a significant advantage. Finally, there's Skein-512. It is an ARX hash which is quite fast in software and is a solid choice, though it does not have nearly as much analysis as many of the others. Overall, I would suggest SHA-512.


How can i Identify and use hash function given enough text and their hash?

Ultimately, reverse engineering is the most comprehensive method, and it is certainly possible. There is also a dedicated Stack Exchange site for reverse engineering. Arguably, by trying out known passwords and checking the resulting hash values, you have already begun to reverse engineer that piece of binary software. There is nothing qualitatively special to decompilation -- what constitutes reverse engineering is the attempt at understanding, and you have made the first step along that path.

As for legality, it depends a lot on jurisdiction. What is traditionally said is that reverse engineering for interoperability purposes is fair game in Europe (as long as you just use, not publish, your findings) but maybe not in the USA. Laws on that subject tend to change fast, with things like the DMCA, so don't put too much trust in the reliability of the Tradition.

I suggest that you use the binary software to check the password for each user when that user logs in, but then, since you have the password available at that point, rehash it with another, secure and fully specified password-hashing function (say, bcrypt); that new hash will be used to verify further login attempts for that user.

That way, you may gradually move all password hashes to a new system, and after a while you will be able to decommission the old system with the binary piece of hashing. In any case, that old hashing is weak, since it is unsalted (an attacker who can look at the database will be able to speed up attacks a lot through parallelism), so you should build up a transition plan to a safer system.


Is it possible to Spoof Another Machine's MAC Address on LAN?

You cannot change the MAC address on the remote machine. The method you are looking for will keep answering the arp requests and fullfil them your supplied MAC. Ettercap is the tool used. Here is great description of how arp poisoning works. This does exactly what you are asking.


TLS connections have 3 important, distinct properties:

privacy, i.e. protection against eavesdropping
authentication, to make sure the parties communicating are really who they pretend to be
integrity, meaning the data cannot be modified during transmission

It seems your opponents argue only against the first one, but the other two are critical for most applications. For DP-3T in particular, lack of authentication would mean an attacker could intercept a transmission and drop it while the application would think the code has been transmitted successfully.
And more generally, TLS nowadays is cheap and easy to setup. You would need a very good reason not to use it rather than one to use it. In fact, at least for iOS, it is explicitly required that an app uses transport security, and exceptions must be justified.


Someone shared their google account with me, am I vulnerable?

Google login works in a very not mysterious way. You log into google, and your device remembers it's logged into google. If you have multiple accounts on your device, then you have multiple accounts on your device. This is of course a one way street. So unless they have logged into your account, then no, they have no access to your account.

Of course you can always check, just to be sure.

Log into your google account
Go into My Account(on google.com, click your avatar, select My Account)
Click Security and Logins
Scroll down to Devices And Notifications
Review Devices. If you see one you don't recognize, deauthorize it.

This way you can be sure only you have access to your account. Of course you friend can do this too, so don't go giving away his info.


When prompted to add a certificate or profile to connect to a secured WiFi network, how can I tell if it's safe to install it?

Never install a certificate you don't trust.
If you trust a certificate, the company/ person that issued the cert can mitm (and certainly will) any https connection you make. The system is often used by companies to monitor their employees activities. Would you accept that for your personal data ? I think not...


Will my company’s VPN work internationally, and will it alert them or display as a security threat?

Only your company can know the answer to that question.  However, I would suggest that there is still a firm answer here.
Europe may be blacklisted
If someone at your company wanted to track people connecting internationally, then they certainly can.  However, that wouldn't be my concern.  My concern would be that I would show up and find myself blocked entirely.  I've met many IT administrators here in the US who reflexively block international IP addresses simply because there is no legitimate need to accept international connections, but international traffic still causes trouble.  To pick two real life examples, I once watched someone block most of Asia because the Baidu spider happened to be hitting resource-intensive pages on a web server, and I saw someone block large sections of Europe because of automated port scanners coming out of Eastern Europe.  For companies that work exclusively in the US, it's not crazy to ban access from other parts of the world.
Here is a question from someone who discovered that their health care provider's website blocks all connections from anywhere outside of the US.  I figured it was worth a mention as an example of one (of many) cases where a company restricts international traffic.
You can always try to test it from here
If you can find a VPN with an exit point in your destination country, you could try signing up with that VPN service, using its exit point in Europe, and then connecting to your work VPN.  Setting up a double VPN can be a pain (I've never actually done it), but it's still less of a pain than showing up in Europe and having to call your boss because you can't work.  You may also find out if they track connections from Europe, if your boss calls you up and asks what's going on.
Summary
As a result, it's possible that you'll show up and find you can't connect at all.  It's also entirely possible that you'll show up, have no problems, no one will find out, and no one would care if they did.  Unfortunately the only thing that can be guaranteed is that your company could find out if they wanted to, and that they might have already blocked international traffic for reasons completely unrelated to employees like you.
Ultimately only your company can answer this question, and you're going to have to decide which you are more worried about: showing up in Europe, being unable to work, and having to call and fix it, or talking to your company about it.


A different checksum only means that the software on your computer is not the same as the official version of the software. It does not necessarily mean that an attack is taking place.

A transmission error may have corrupted the data in transit.
Your download mirror may have inserted something benign to the software distribution, such as a thank-you or a request for donations.
Your download mirror may have given you the wrong version of the software, for example if they are slow about updating the software on their website.
Someone may have inserted a malicious program into your distribution.

If you've eventually gotten a version of your software that matches the officially published checksum then I wouldn't worry too much.

A few other observations:

Checksum values are not stable- small changes in the software can lead to totally different checksums. The fact that your checksum is radically different doesn't mean anything.

It would be exceedingly difficult for an attacker to display a fake checksum on your machine. They'd need to know what program you're using to calculate checksums, and they'd need to somehow install a malicious version of that program. If they're able to do that, then they've already got administrative access to your machine, making the purpose of further attacks a little unclear. In my mind it'd be more likely for them to hack into the software author's website and change the official checksum listed there.

Many sites use a download link that sends you to a random mirror as a simple way to provide load balancing for their mirrors. The fact that you've gotten three different checksums is not necessarily a red flag in my mind.


Should I use a firewall even though I am on a private vlan inside a data-center?

It seems you've mostly answered your own question. The only protection a firewall can give, on an isolated network, is from computers/users of the same network. Your firewall won't protect you from Internet hackers - the isolated nature of your network already does that.

What it will protect you from is malicious users or software installed on other systems within your isolated network. As you say, this can help prevent a user on one system from connecting to other systems via SSH. It will also help protect you in the case that one of your systems gets infected with a worm which tries to automatically propagate across the network.

For the highest security, you want your systems and users to be restricted so that they are only capable of performing actions which are absolutely necessary to fulfilling their business function. Firewalls are an essential tool in implementing these restrictions, even on isolated networks. However, it is up to you to decide if the risk (e.g.: of malicious users on the network, or another system being infected with malware) is really high enough to warrant the added complexity and administrative overhead of using that tool.


When running shell scripts, is it safer to pass sensitive information using stdin or as a string option?

Passing it via stdin is more secure, since arguments are visible in the process tree.

Passing a secret value as an argument is typically more risky. Whenever something is passed as an argument, all other processes running under the same user (and sometimes all other users' processes, period) will be able to view the arguments for each process. This is why you can see arguments by running ps aux. Passing a value via stdin, on the other hand, sends it through a file descriptor. This descriptor will not be readable by unprivileged processes. If your threat model involves other malicious, local processes, you should send the sensitive material through stdin.

Passing data through stdin involves passing it through a file descriptor which the program can read using standard IO calls. In this case, it will be just as secure as opening a file to read from it. Command line arguments, on the other hand, are kept in a process' argv in memory. A program simply has to access that address of memory to view the arguments. This data is, however, visible to other users via that process' /proc/<pid>/cmdline. This is actually also the case for environmental variables on some systems (especially older *nix systems), so passing secrets through the environment is not necessarily a good idea either.


Is forcing users to use a strong password effective?

Allow any passwords. Just highlight consequences.

Your scheme is weird and alien to users and I believe many people would rather stop using your service than comply. Instead of letting them choose their own password, you're forcing them to remember one you chose for them. This is unacceptable to most people. You think that you're giving them a choice by "try again", but the difference in user experience is about same as ATM vs one-armed bandit.

Keep in mind that the biggest issue is human factor. What you should avoid in the first place is passwords being written on a whiteboard. These guys had a very secure password. And then it aired on TV.

If you want to ensure no one at your side would be able to crack it, then what you need are internal procedures, not monkey-training users. Maybe a system where access to salted passwords is protected by the same retry limits as the user login panel. Besides, it's not important to make it impossible for workers to gain access. Clerks in stores have unlimited access to cash registers. What prevents theft is awareness of unavoidable consequences. Use admin-session recording. Use "minimum 2 persons to access" procedures. This is how banks do it, because strong user passwords can't protect everything.


Can Windows 7 hibernation files be recovered?

Answering your questions:

  [...] hibernation basically moves memory data from memory to hard disk. First of all, is this true? And if so, is it possible to recover the deleted hibernation data and use it to access memory data before hibernation?

In a general sense, yes, hibernation copies data from memory, stores it to a disk, turns on some flags on the OS. When you turn the computer on again, the OS sees the "flag", knows that have to read the hibernation data, and proceeds accordingly.

If you can recover the deleted hibernation data, you can know what was in the computer memory before it was hibernated.

  Also, would it be possible to "boot" using this hibernation data? (So basically force windows to wake up from hibernation by using hibernation data although the system was not put into hibernation)

Yes, just depends on the OS you're using, you would just turn the "flag" on and the system would read the hibernation data again.

For further information, take a look at this wikipedia and the corresponding notes.