Idea for hiding your mobile phones' location, and still be able to place and receive calls. Any suggestions?

You haven't stated the security problem you are trying to solve, so I'm going to default to "defeating government snooping".

There's no reason this wouldn't work from a technical point of view, though from a business perspective it is impractical and would get very few takers. The primary problem with it is that it will be challenging from a wifi access perspective. Mobile telephone companies have spent billions on the infrastructure to establish quality coverage over wide areas, you're talking about people giving that up in favor of wifi services that are spotty even in metropolitan areas. I personally wouldn't use it.

Also, in order to really ensure privacy you'd have to develop your own mobile telephone OS, and prevent it from going to any app stores. Who knows what back-doors the mobile company put in the android distro they put your phone? Installed apps can have all sorts of snooping capabilities, so if you don't control for these things there's no point in your design.

Lastly, say you build this and some people start using it, nothing is going to stop governments from knocking on the VoIP provider's door and demanding that they give them their phone records. In fact, in many places any phone provider is already compelled to by law. So you'd be substituting snooping on mobile networks with snooping on VoIP. The fact that you are going to put these calls into the phone system at all defeats the whole purpose. Information from the VoIP provider could be used to determine the location a call was made from using the IP addressing used in the VPN that was set up. You could obfuscate that by running some VPN proxies for people to connect through, although being that they'd have to be set up beyond the reach of the government you're trying to defeat you're going to have latency issues.

If you want to deliver secure communications then encrypted point to point connections are a good way to go. You can use mobile providers' own networks or WiFi for transport, whatever's available. Network availability would be much better than if you rely solely on WiFi. It doesn't matter that it goes over the mobile network as it's encrypted, and if there are secure servers somewhere out there to act as proxies (think TOR) then the end points of the connections are harder to track. Not that Skype already does much of this, however their operations and code are closed, I personally wouldn't treat it as secure or private.


How can browser select suggestions for my private searches?

If you are truly clearing all the local records when you close the browser, are not logged in to any accounts and are connecting through a VPN, then it is possible they are using information your browser itself reveals about you to guess at who you are.  Certain information can be provided by a browser to the server.

Things like available font lists and lists of installed plugins can be very unique and result in being able to detect your system.  It's also possible that you haven't killed all local records.  Browser cookies are not the only way to store information.  Various plugins (such as Flash, or even built in features of the browser) can provide additional storage capability or track what you are doing locally.

Are you sure that you do not have any of Firefox's built in search optimization stuff turned on?  Firefox has sync features that keep an online record of your activity to allow it to follow you from one device to another.  This could easily be responsible for the observed behavior.  There can also be other more stealthy local records such as storing cookies via Flash.


What are the security vulnerabilities for a website that allows me to login by POSTing form data programatically?

This doesn't sound like a vulnerability at all.

If I understand you right, uou do have to use your own username and password? Making a POST request with those is exactly what your browser does once you hit the logg in button. That you use another program to send the request is impossible for the server to know, and doesn't matter much anyway. Any client is as good as any other. There are no "authorized clients", there are just clients.

Think of it like this. If I write a program that sends exactly the same HTTP requests as Firefox do, how could your server differentiate between them? All the server see is the request, not the client itself. If I download the source code for Firefox and modify it for my purposes, how would your server know? (This, by the way, is also why the server can never rely on the behaviour fo the client to enforce security.)

Also, if this were to be considered as a vulnerability, how could an attacker exploit it? An attacker wouldn't know your password, so they couldn't POST it, no matter if it is done "programatically" or from a browser.

You mention that the cookie is "insecure". If you mean that it does not have the secure flag set, then that is bad practice. And it might be a sign that they are serving part of their site over plain HTTP, which is no good either.


What should happen when an account is unlocked?

Best practice is to, first, verify that the person requesting the unlock is the owner of the account. This can be tricky as it's the source of many social engineering attacks (these days it's quite simple to find personal identifying information for a target). If this is for an internal corporate user then often I've seen things like Employee Number used (this is decent because it's not something that an attacker would typically have), but also I'd recommend using another factor, e.g. calling the user's cell phone or emailing a secondary account for verification.

Once the user is verified then the administrator should request more information about the lock: did they cause the issue, or was it caused by an attack? If caused by an attacker then escalate the issue to the Information Security team, who should work on gathering additional information about the attack and take steps to prevent future attacks.


Controlling windows server on Amazon Web Services

First of all: ISO/IEC 27001 is the norm that specifies the requirements for the establishing, implementation, maintenance and continuous improvement of an information security management system. Security controls are specified in the ISO/IEC 27002.
In general the ISO 27000 series (including ISO/IEC 27001 and 27002) does not recommend products or certain technologies to use for implementing a control. A typical control in the norm is described in a rather abstract way. Here's an example (freely translated from the German version):

13.2.1 Guidelines and procedures for the transmission of information
Formal transmission policies, procedures and measures should be in place to protect the transmission of information for all types of communication devices.
Instructions for implementation
In the context of the procedures and measures to be followed when using communication facilities for the transmission of information, the following points should be taken into account:
(a) developing procedures to prevent transmitted information from being intercepted, copied, altered, diverted or destroyed;
(b) methods of detection and protection against malware transmitted through the use of electronic communications equipment (see 12.2.1);
(c) procedures for the protection of transferred sensitive electronic information, which are in the form of an annex; [...]1

So to answer your question: there is no one true "ISO-27001 compliant recommended way of connecting to Windows Servers on Amazon", because there is no mention of which technology, protocol or product should be used. This is something you should decide, but what is important here is, that in the end, it should fit the descriptions of a control. So for instance RDP can be used securely but you have a lot of setting up to do which can be complicated.
To come back to your example: Using a cloud provider is fairly easy and using one that is ISO 27001 certified is also a plus in your own audit. To get certified yourself, you will have to read the norms, understand them and only then implement a control that fits the requirements within your scope.
1: Quote taken from DIN ISO/IEC 27002:2016-11


Understanding the difference between POST and PUT when securing against CSRF

By default, CSRF is only even possible for a few verbs - GET, POST, HEAD, and in some cases OPTIONS - because those are the only verbs possible for cross-site requests at all. Of those, only POST should ever change state on the server, although of course in practice people allow GET requests to change state all the time (logout CSRF via a GET request to //site.com/logout for example).
It is possible to enable CSRF risks for other verbs by configuring CORS on your server and allowing the remote site as an allowed "Origin", allowing the relevant verbs ("Methods"), and allowing Credentials (typically cookies) in the cross-site request. However, by default that's disabled, and even if you enable it you should only ever allow it for specific, trusted sites; essentially taking down some of the same-origin policy between your site and the allowed "Origin" because you trust them to be secure and non-malicious.
I don't know what Spring Security is doing for CSRF protection on non-GET/POST/HEAD requests, but if it's getting in your way and you haven't enabled CORS, you can safely turn it off for those requests only. There's also ways to just render CSRF a non-issue, such as using a bearer token (in the HTTP "Authorization" header) instead of cookies; bearer tokens aren't sent automatically, so they must be manually included via script, and if the attacker can do that then they just already know the victim's session token and there's no need to forge a request from the victim's browser. The "SameSite" cookie flag can also block most CSRF risks, although it's not supported on very old browsers and also in "Lax" mode it doesn't protect against CSRF via top-level GET requests (i.e. setting window.location) although it does still protect against GET-based CSRF via things like iframes or image tags (and also you shouldn't have state-changing GET requests anyhow...).


I suspect they are oversimplifying. You're correct in that generally two way communication with a spoofed IP address is not possible. There were tcp sequencing attacks but they have not been practically possible for years.
However, there are so many other ways to hide your IP address, e.g., tor, pivoting off compromised hosts, using a VPN that won't keep logs, free WiFi, etc..
It's probably just easier for them just to say spoofed than to enumerate all the ways you can mask your address.


Passive fingerprinting of email client, based on email headers

Are there ways to passively fingerprint (infer) the operating system or mail client that an email sender is using, based upon the headers of an email from that sender?

Yes, but they are extremely prone to errors and very easy to spoof, either intentionally or unintentionally (e.g. some high-end firewall systems will "repack" a message after removing/sanitizing attachments, modifying some information).

Apart from the X-Mailer header, you can glean some information from other fields such as the message-id and multipart boundaries, if present. Both should contain a unique sequence, and different systems generate that in different ways. Some MUA will generate a message-id of their own, other will leave the chore to the server; so you see 'DE9E2BFC.12345@gmail.com' and you know it's a GMail customer and nothing more, while o8xp315ahi3207wv6gbl5tfiedsaelntas@4ax.com is an ID produced by Forté Agent, a software which only runs on Microsoft Windows.

The old Eudora up to 6.1 had a X-Sender header which also revealed the "persona" used to send an email.

Microsoft Outlook uses, I think, boundaries of the form _NextPart_XXX_0000_HHHHHHHH.HHHHHHHH where H is a hex digit and XXX represents the inner sequence number (000 onwards), while Mozilla Thunderbird (which also adds a User-Agent header) uses a boundary of "------------0x0x0x0x0x0x0x0x0x0x0x0x" where x is a 0-9 digit.

In several cases you will see that a part of the uniqueid is actually a timestamp, which can also double as a verification of the date header.

So, some information is there -- but you'd need to build a fingerprint database. Also, as I said, it's relatively easy to modify a single header, and maybe even all of them; you'd have to take this into account and see if the strategy still fits your purpose.


First, in order to get all the request you'll need to poision the clients too - if you'll poision only the switch, you'll get only the answer to the requests. Because the client will transfer the request to the switch and the switch will transfer further.

Second, a lag will occur as you add another node in the transport link (actually it's more than 1).

Third, afaik there wouldn't be any other consequences besides lagging.

Fourth, the table will get back after you stop poisioning - the client will try to request, see that there is no response and will start ARPing.


Let a server which only requires a password for opening a session; no username. Let's imagine that user 'Alice' has registered, with password 'ILoveBillClinton'.

Now, a new user wants to register; let's call him Bob. Out of (bad) luck, Bob elects to use password 'ILoveBillClinton' too. Such collisions happen in practice; indeed, even if users choose passwords with 30 bits of entropy (an already optimistic figure), it suffices to have 30 thousands or so users to have a good chance of triggering such a collision (this is called the Birthday Paradox).

The registration server then has three ways to handle this situation:

The server warns Bob about the collision. Bob then immediately learns that there is another user with the same password, and since the server does not require the username, just the password, Bob gains immediate access to Alice's account.
The server does not warn Bob about the collision, but just ignores the registration. When Bob actually connects, he has the surprise of being greeted with a banner stating "Hello, Alice !". Bob has gained immediate access to Alice's account.
The server does not warn Bob about the collision, and replaces Alice's registration with Bob's registration. Bob has his own account, alright. But when Alice logs on again, she types her password, and is greeted with "Hello, Bob !". Alice has gained immediate access to Bob's account.

None of these methods is satisfying.

The entry of the username would not be necessary if password collisions did not happen (or would happen only with negligible probability). But as long as passwords are chosen by human minds and stored in human brains, collisions will happen, and a username (or user ID or any similar discriminant value) will be needed.

Edit: as @mikeazo alludes to, if the passwords are not chosen by the user, but generated by the registration server, then the server can enforce uniqueness and avoid this problem. However, in practice, human users do not like machine-generated passwords.

Also, lack of username prevents user-specific salting, which is a problem for password storage, as long as passwords are of sufficiently low entropy to be exhaustively scanned (see this answer for details on how password should be hashed, including salting). This happens even if the passwords are server-chosen (with enforced uniqueness). Unless you can convince your users to remember long and random passwords which they did not choose...


Can you add random useless code to a virus to change its hash so that no 2 users have the same hash?

Antivirus is only ever going to catch broad attacks, or default payloads from commonly used tools.

A skilled attacker will be able to modify, encode, or obfuscate his payload to avoid this type of detection.

That being said, most antivirus will also search the executable file for strings known to only be found in the malware. For example, here is a snippet from Invoke-Mimikatz.ps1:

$e_res2Field = $TypeBuilder.DefineField('e_res2', [UInt16[]], 'Public, HasFieldMarshal')

Antivirus can search for strings like this within the file, and then flag it if it detects a match. This can also be defeated fairly easily. One example would be to take the file and break it up into small strings. Like this:

"$e_res2Fi" + "eld = $TypeBui" + "lder.DefineField('e_res2'," + " [UInt16[]], 'Public, HasFieldMarshal')"

(not trying to be syntactically correct here, but you get the idea)

And then use a wrapper script to piece the strings together in memory and execute the original code.
Another more common example would be encrypting the primary payload and then have a stub decrypt and execute the payload in memory.

Some antivirus will also conduct dynamic analysis, where the file is ran in a virtualized or simulated environment to detect the actions that the executable would perform, or to analyze post decryption memory.

This type of antivirus can usually be bypassed simply by consuming enough of either time or memory before decrypting the primary payload.


To expand on @tlng05's point, rootkit authors are professionals, often with decades of experience. Unless you have decades of experience fighting rootkits, then they'll know about more hiding places than you do :P

If you suspect there's a rootkit, then your only choice is to wipe the system. This is a classic example of Ken Thompson's reflection on trusting trust "you have to trust the people, because you'll never find the exploit".

Next time, I suggest being more strict about who you give root access to.


Question about ISO 27001:2013 scope definition

27001 (2005 or 2013) is less prescriptive than most people seem to think. It is completely up to you how you set the scope, just remember that it will appear on your certificate.

If the external stakeholders (customers, partners, shareholders) invested in your certification don't think it is sufficient then the certification itself might be useless for your purposes.

If the second company is out of scope, then the auditor won't consider it of itself during assessment. Its policies, procedures and controls won't be relevant.

However, that isn't to say that things excluded won't cause you some problems indirectly. You rightly mention other people having access to your workspace might be a problem.

Section 11 deals with this element: 11.1.1 (Physical Perimeter Security) and 11.1.3 (Securing offices,
rooms and facilities) are where you will need to demonstrate effective controls on your Statement of Applicability.

The standard does not prescribe what the controls are, merely that you should have them. An auditor's job is to prove that you have them and that they are not obviously ineffective - not that they are effective.

The problem certainly isn't insurmountable. A range of controls around auto-locking screens, 802.1x on network interfaces and employees reporting any information security incidents pertinent to the presence of the other company's employees is likely to be enough to satisfy an auditor in most cases.

Indeed, in some organisations working with privileged information with members of the public present is necessary (the booths on the floors of retail banks, for example) and that is not a barrier to obtaining 27001 certification.  Of course, lots will depend on your environment and your auditor.

UKAS auditors tend to be the most stringent but at the end of the day play by the same rules -- is there a control? Is there evidence it isn't working?

Finally, to your datacentre point: as an Information Processing facility it will impossible avoid repeated mention during audit. If the facility itself is 27001 certified (doesn't matter on the version) then all you need to do is produce their certificate and Statement of Applicability. If it is not, then it is likely the auditor will want to visit to test the security they provide on your behalf.


What are the risks of using OAuth for authentication when in control of both ends?

The problem with OAuth2 is that the authorization_code given out by the OAuth2 Provider, is not bound to the client_id of the OAuth2 Client.

This means that if a user authorizes a malicious service to access its OAuth2 resources, the malicious service could use the authorization_code it received to 'impersonate' the user on another service, if the other service mistakes authorisation for authentication.

To answer the question:

IF you can guarantee that you control ALL clients ALL the time, you are probably fine. However, you are still using a OAuth2 outside of its intended scope. Using a security protocol outside of its intended scope is generally considered very bad practice.

For example, there is a real risk that somebody, at a later date, decides to alter the scope of the project; it happens all the time.
If this happens, you might suddenly find that the assumptions you made earlier, are no longer true. If these are the very assumptions that made you feel confident enough to go ahead an build your authentication on bad practice, your authentication is suddenly vulnerable to impersonation attacks. Chances are, you will only find out when people start reporting strange incidents.

In summary: if you want Authentication, you should use OpenID Connect instead. OpenID Connect is the authentication layer build on top of OAuth2.


Question is do I need to additionally connect classic certificates to be sure even OTR ask queries will be encrypted?

As long as you implement OTR correctly using libotr or the specifications, you do not have to deal with classic certificates from PKI. OTR operates using the TOFU model, with the optinal ability to verify another's fingerprint through an external channel.

  If it will be good idea to connect both of OTR and SSL, what one must cover other?

TLS operates on top of the TCP layer. Any arbitrary TCP traffic can be encrypted using TLS, as it is completely format-agnostic. OTR on the other hand is designed to encrypt printable characters and convert it to plain ASCII. It is not even possible to put OTR over TLS, since OTR takes text as an input and spits out base64 ASCII as an output. Have TLS encrypt the OTR stream if you do this.


Your guesses are correct:

it uses a random salt.
it needs that salt to perform the decryption is correct.

From the documentation:

  This encryptor uses a salt for each encryption operation. The size of the salt depends on the algorithm being used. This salt is used for creating the encryption key and, if generated by a random generator, it is also appended unencrypted at the beginning of the results so that a decryption operation can be performed.

The salt is appended in the encryption result, so it will be available during the decryption process.


How to check if my PC's HTTPS/TLS connection is monitored or a key-logger is installed?

This was supposed to be an Antivirus program.

  But after installing this program many of our colleagues have been
  facing some issues like a performance problem, application slow
  responsiveness, slow network connection.

That is completely normal and expected behavior from many Antivirus programs, especially during scheduled scans.  In other words, those aren't reasons for you to say "Hey!  I think this might not be Antivirus!".

  We can't uninstall the problem. It asks for the password. We don't know that.

Also completely normal.  That's a standard feature to prevent users from turning off their protections in order to regain the performance they lost - and, incidentally, to make it harder for attackers to turn off the Antivirus to evade detection.

  We can't stop this process. If we kill this from the task manager it restarts again.

Again, completely normal, for the same reasons.

  I have a suspicion that it might be monitoring all of our actions like every keypress (keylogger).

Nothing you've indicated so far suggests this - keyloggers are usually far less intrusive than Antivirus programs.

  We use this laptop to access our personal emails, facebook, bank
  account. It will be a great violation of privacy if they are
  keylogging or somehow managed to monitor our SSL communication like
  HTTPS websites skype, facebooks messages

Depending on your location, it would be a violation of your privacy, but might still be completely legal.  In the US employers have the full right to monitor anything you do on the equipment and networks they provide for you to do work for them.

...but I really don't see anything here that suggests that.  Sounds like they just installed Antivirus.

  Is there any way to be sure of if they are doing anything like and confront them?

This question discusses detecting keyloggers, but the short version is, "not really."

This question discusses detecting corporate MITM, which usually boils down to examining the certificates of sites you visit, and checking your computer's Trusted Root Certificate Authorities.  This is relatively easy to detect; the modern (lovely) tendency to use TLS for everything increases transparency.


Can my web accesses be known by individuals?

A private individual would have trouble, but many private companies know what you do online.  Your ISP certainly knows.  Marketing companies that have deals with large numbers of websites can track you from one site to another if they have agreements with those sites.  Websites themselves can also tell what IP address you connected from.  If you use single signons like using your Facebook account on multiple sites, then Facebook can tell a decent amount about where you go.  There are also hints about where you have gone left on your computer unless you clear your cache, temp files, cookies and history, though someone would have to have access to your system to make use of it.

If the security "expert" was claiming that any person can tell what any other person is doing on the Internet, they were extremely mistaken however and are not an expert at all.


How are "security questions" not a major security hole for any application that uses them?

Email password reset is not particularly secure either, since it means that if you manage to compromise someone’s email account you can take over all of their other online accounts. At least with well-chosen security questions (which would not include a pet’s name) they are unlikely to be used by the user on another website, so that a compromise is restricted to that one account. The truth is that security is a trade-off with convenience, and there’s no way to authenticate users that is both reasonably secure and reasonably convenient, so you have to decide which is more important.


Is it safe to use Python package managers like pip, easy_install or conda?

I setup MITM for pip to pypi.python.org and it seems that pip does indeed validate the certificate. It fails with SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]. Maybe I will have more luck with other repositories...

Pip may not be checking gpg signatures but it's not like you are downloading from untrusted sources. For example, Linux packages are spread across mirrors all over the world, and without gpg it would be very likely that some of these packages would be compromised. In pip case, the only source for download is pypi.python.org which is using Fastly CDN for distribution instead of untrusted mirrors.

I don't know conda, never used it.


How to check www.abc.com/?page=xyz is vulnerable to RFI or not?

Generally if you're looking to test for RFI the way to approach it is to place a URL that you have control over as the parameter.  That way then the URL is accessed you can look in the web server logs to see if you had a request from the server your assessing for that page.

As to whether this website is vulnerable, to be honest it's not possible to tell definitively from the information at hand.


You are really looking for a better explanation of what the BEAST attack does, then this site is a great reference.

  How Would an Attack Take Place?

  BEAST has three conditions that must be met for this attack to take
  place:

  JavaScript or applet injection into the same origin of the web site
  Network sniffing of the connection must be possible
  A vulnerable version of SSL must be used which is using a block cipher

An attacker could inject a java applet into the page with either XSS or intercepting a request for a valid applet.

As far as the exact method of "breaking" SSL.  The article I mentioned, provides some great links in the fourth paragraph.

This blog post provides a great technical breakdown of how the BEAST attack works.

Security impact of the Rizzo/Duong CBC "BEAST" attack


If you are having issues with hydra and ncrack, I might suggest trying Patator, but really you want to troubleshoot what is going on.

For a thorough check that also involves an additional layer of testing, try — https://github.com/SySS-Research/Seth


Can one then establish the recipients of the encryption?

Ordinarily, yes. The recipient's Key ID is included in the metadata.
This can be disabled if you use --throw-keyids option.

Likewise, same question for a GnuPG signed file? (i.e., Can you at least establish the signer, without authenticating their signature, without having the key in your keyring?)

Yes, and as far as I know there is no way to disable the inclusion of the signer's key ID in the signature data (it wouldn't make much sense to do so). If this information needs to be hidden, you should sign, then encrypt the signed file with the throw-keyids option.


"SSL decryption" (through a firewall-controlled CA and on-the-fly MitM) is a feature offered on most "expensive" firewall appliances, so one can say that most big companies can deploy SSL decryption. Whether they really do it is another matter. Common reasons for not using that feature include:

Legal concerns. In many jurisdictions, employees are allowed some level of personal usage of the company-provided computers (in the same way that people can use the company phone for short personal calls), and snooping on a communication between the employee and his bank or physician would be food for litigation.
Compatibility. Many "SSL decryptors" do a somewhat flaky job; e.g. the fake server certificate that the client browser sees contains a 1024-bit RSA key that triggers warnings, or CRL/OCSP for that certificate is not properly supported. And, of course, that MitM breaks client certificates (e.g. smart cards).
User resistance. Users simply don't like the idea of their SSL data being inspected.

That last point is interesting. Firewalls that do SSL decryption use a special CA and on-the-fly fake server certificate generation for ease of deployment, but this is hardly the only method to do it. On a company-controlled office computer, the sysadmin may perfectly well install locally some software that hooks with the SSL libraries and inspects data as it flows, outside of the SSL protection. Most antivirus software do just that; and it does not cause so much user fretting. Therefore we may say that what users don't like is not that their data is inspected; what they really abhor is knowing that their data is inspected. Ignorance is bliss.

Personally, when I see such a "SSL decryption" system put in place, my first thought is not "OMG they are looking at my SSL !" but rather "At least they are open about it".

I don't have stats -- I think nobody has, except possibly appliance vendors, but they don't tell (honestly, who wants to say: "my product has a nice feature that nobody uses" ?). But my feeling and experience tell me that company-wide SSL decryption through a visible firewall-controlled CA is still something rare, whereas hidden, transparent inspection done directly on the client machine is highly prevalent. The "fake server certificate" method will become more common in the future, because it makes it much easier to support content filtering for user-provided devices (even if not going full BYOD, companies that provide a complimentary "external" WiFi for their employees prefer it when even that non-privileged network does not become a cesspool of malware and videos of questionable legalities).


Why are Wikipedia's listed DES semi-weak key pairs 16 bytes?

A weak key pair is just that, a pair of keys. So a pair of 8 byte keys is 16 bytes.

For their example weak keys:

0x011F011F010E010E and 0x1F011F010E010E01

This can be broken down into:

01 1F 01 1F 01 0E 01 0E and 1F 01 1F 01 0E 01 0E 01

The first byte of the first key is 01, the second byte of the first key is 1F, etc.


Pentesting web applications with unique strings in URL

Burp supports Macros and Session Handling Rules that are designed to cope with this kind of situation. For example, you can configure a macro that fetches a fresh token, and a rule that updates the current request. This can be used with all Burp tools, including Intruder and Scanner. There's some more information here.

The built-in rules cannot update tokens in the URL. However, the Custom Parameter Handler extension lets you do that.

It can be a little bit fiddly to set this up, but it is possible to configure working session rules for most sites. You also have the option of coding your own extension.

Affiliation: Burp Suite is a commercial product of ours.


Is context establishment a repetitive process in standard ISO 27005?

TL;DR:

  [...] is this a repetitive task that has to be done in the beginning of each risk assessment process (given that risk assessment conducted for certain limited scope such as a web service)?

Exactly. But the part you put in brackets is really important. Take a look at this picture.

You can see here that context establishment takes place before every risk assessment. The scope is defined within the context establishment.

Long answer:

First of all, we have to answer the following question:

What does 'context' mean within the ISO/IEC 27005?

Consider the following note:

  ISO/IEC 27001:2005 does not use the term “context”. However, all of Clause 7in ISO/IEC 27005 relates to the requirements “define the scope and boundaries of the ISMS” [4.2.1 a)], “define an ISMS policy” [4.2.1 b)] and “define the risk assessment approach” [4.2.1 c)], specified in ISO/IEC 27001:2005.

and the output of the context establishment process:

  Output: The specification of basic criteria, the scope and boundaries**, and the organization for the information security risk management process.

These three "items" establish the context.

Basic criteria

Basic criteria are the criteria that detail your risk management process. These criteria follow your risk management approach and this approach follows the objectives and the scope of your risk management.

Basic criteria can be:

Risk evaluation criteria
Impact criteria
Risk acceptance criteria

I don't want to go into these criteria too much, because they are all well described within the norm.

Scope and boundaries

The scope and boundaries always refer to the information security risk management. They need to be defined to "ensure that all relevant
assets are taken into account in the risk assessment. In addition, the boundaries need to be identified to address those risks that might arise through these boundaries."

This part is crucial and probably the most complicated in the whole process. If your scope is too wide, the gathering of information can take so much time, that once you are done you have to start over again, because so much has changed in the meantime. The more time you need, the more money and ressources will be spent. If your scope is too narrow, you will exclude a lot of and important information and therefore a lot of possible risks. The worst part about this: there is no standard or "good" recipe for this. If you have never done this before, get help from the outside and go through this process step by step.

Important note that is often forgotten: "Additionally, the organization should provide justification for any exclusion from the scope."
Do not just leave parts of your organization out. This isn't only meaningful for an audit, but it's also helpful for you and your team. Why would you choose a scope the way you did and why does it make more sense than any other way?

Organization for information security risk management

This one is pretty easy (to understand): your risk management process has to be organized. Roles and responsibilities have to be alloted, and all formal activities that come with a risk management process have to be conducted. This is all very straightforward and highly formalized.

All quotes as well as the figure are taken from ISO/IEC 27005, Second Edition 2011-06-01


Just found out my internet was routing through a proxy, how screwed am I?

This all depends on the proxy itself. A proxy intercepts, and redirects. Everything going towards the Internet was intercepted, but it doesn't mean that all was readable. When you log into certain sites (banks, to buy something) most use SSL which means that, unless the proxy was intercepting with a trusted certificate, most data would be encrypted. If in the event the proxy intercepted SSL, and was capable of forging a certificate, or making you believe a certificate was trusted, then you're data is readable. You would have gotten a certificate error via your browser: "Warning this site uses an untrusted certificate..."

Can you elaborate more on the proxy server. E.g. the IP (if possible). Some ISPs use proxies (rare) to cache and provide content quicker.

ADDED

The IP space belongs to Strato in Germany http://bgp.he.net/net/85.214.0.0/15#_whois and is listed in a lot of "free proxy" like sites. The bigger question for you is, how did your machine manage to get proxied in the first place. This is likely caused by some form of malware that made its way onto your machine if you did not configure that proxy. As noted, SSL could have been stripped so that is something to take into consideration.

Personally, I would try and determine how my machine got compromised, I would clean it up, preferably re-install from a clean source, then go and change all my passwords AFTER the fact I cleaned up. (Makes no sense to type much via way of credentials when you don't know what's on your machine)


Suitability of encryption algorithms for different content types

No. All modern algorithms (eg. AES) will provide ciphertext indistinguishability, so -if everything is done properly- it doesn't matter the kind of content that you are storing.

Not specific to any encryption algorithm, as it would happen with all of them, but kinda related to the question:

Knowing that it is a PDF (or MSWord, or Excel) would allow some known plaintext for someone attacking the encryption (eg. if I was to bruteforce the encrypted file, I could check if the decrypted content with the candidate key starts like PDFs do).
Simply applying an "encryption algorithm" may not hide the length of your data. You may want to add some padding to the file (or at least use a block cipher mode).
You must use an iv on the files.
Remember that you must verify the contents, not only check if it decrypts to "something". On certain filetypes, a blind attack would be possible where the encrypted file could be modified in order to obtain a different output.


Is there a ransomware variant that checks for file's magic numbers to encrypt?

Yes (I found a sub-version of TeslaCrypt to do that a while back) , but most will only hunt for extensions. Some have different behavior like encrypting full folders with have the majority of files of known document types.
Something as simple as having a .tx instead of .txt will many times keep your files safe.
The problem is that the methods of eliminating any backup varies a lot, but it is important to note that most of them will disable shadow copy, restore points and end-task some related services.


After 5 month without answer, only comments, I like to sum up:

From a discussion in sci.crypt it seems that scrypt is demonstrably secure.
Most people on SO trusts scrypt.
I have seen no one claimed to have a problem with the algorithm itself.

Regardless there might be issues with the implementation. A straight forward implementation of scrypt is potentially vulnerable to timing attacks but that should not be a problem.


How to effectively test for username enumeration risk?

visual differentiation is a consequence of HTML differentiation. It cannot happen that the same HTML + JS + CSS will lead to different visualizations (barring some intentional fudging like, I don't know... time-dependent background colors or animations?).

So you can send out a sufficient number of queries for real users and compare the same queries for fake users; and you must do the same with all unauthenticated endpoints that are accessible.

This means examining not only the "login" URL but also the "I've lost my password, how do I go to recover it?".

For each such endpoint, in addition to the differences in outputs, calculate the average time to answer and its variance (a high enough variance will negate any reasonable timing attack).

You may want to do this twice, i.e. you check user "marcel" once and then again. The series of the "firsts" we call the unprimed series, the series of the "seconds" is the primed series.

Purge the received contents of any timestamp, unique id or user-related information (e.g. "Sorry, password for user marcel is incorrect" should become "Sorry, password for user USERNAME is incorrect" - simple regex here. Careful if some user is called table, html, or body, since that would skew the results).

Then the desired outcome is that, for all endpoints (1),

all the answers for real users and fake users are identical.
the removed parts ("marcel", "admin", "20160920173511.128", etc.) are either all identical, or all different. It mustn't happen that real users get a real timestamp and fake users get no timestamp or a differently formatted timestamp, for example.
the time to answer for each fake user should be very close to the time to answer for a real user. Ideally you want the same mean and variance.
the times distribution for the primed and unprimed series of real users might well be different (usually, the primed times are shorter). If they are, then the same ratio must hold between the primed and unprimed series for fake users.

Point 3 means that looking for a user that is not in the database must take the same time as looking for a user that is in the database and has data to be loaded and analyzed. Achieving it isn't trivial. I've seen random delays added to the process, but they must be based on the user name (same user name = always same delay) (2).

Point 4 could lead to a twist in timing attacks, allowing to distinguish between real and fake users even if for a single attempt the reaction times are the same.

(1) I've seen several systems that will ask your username to help you recover the password, and cheerfully say "Sorry, that username is not known!". A more suitable message would be: "Very well, lserni (if that's really your account), if you're in our database, you should receive an email shortly."

(2) When a username comes by, I want to add a random delay that will thwart most attempts to time the authentication process. marcel is resolved in 85 ms and juniper in 62 ms. Is that because marcel exists and juniper does not, or because their delays were different? You must not know. But what happens if the delay for user juniper is random every time? It happens that I can average resolving time, and the randomness will slowly (depending on its variance) cancel out. So I add to user juniper a delay which was randomly assigned to juniper, but is always the same whenever juniper tries to authenticate. To avoid saving things in a huuuuuge database, what I really do is calculate a 32 bit CRC from the name, XOR with a secret salt, use the result to seed a PRNG, and extract a random number. At that point even if the attacker knows that existing usernames get a 50 ms delay while unknown usernames get 30, he/she cannot know whether juniper's 62ms were given by 50 plus a random 12 (juniper exists), or by 30 plus a random 32 (no juniper). And the 12 (or 32) will not be the same for a different user who will have a different CRC32. So using the same username will not help, but using a different username will not help either. Of course, I need a random range large enough to "overwhelm" the known/unknown time difference.


Are man-in-the-middle attacks against p2p systems realistic?

One of the challenges with p2p systems where there are numerous peers, and numerous short term connections, is that authentication may not be manually checked (it would introduce a high overhead) so placing reliance on automatic protection is quite common.

Where a user connects to only one other, confirming a key or certificate fingerprint to avoid a MITM attack may mean a quick phone call, but imagine doing that for high numbers of connections.


Two general points.

First, the benefit of Passphrases is that they make it easier for users to generate entropy while still remembering their key.  Generating entropy through randomized characters is hard - and the harder something is, the less people will do it.

The reason that XKCD comic is so cited isn't just the math - it's that people who haven't seen the comic in years can still tell you what that password is.  That's the point of the comic: that those bytes of entropy were easy for a human to remember.

Second, you might want to take a look at:

https://wpengine.com/unmasked/

The main highlight?  The average password entropy is 21.6.  Aka, it's off by a factor of 2-billion from your 94^8 number.  The reason?  Users don't choose random ascii characters.  They don't choose random letters with randomized capitals.  They don't choose randomzied letters.  They simply choose a word and decorate it.

Basically, it's easier to get a lazy person to generate entropy through a 15-character passphrase than it is to get them to generate entropy through a 8-character password.


Can CSRF attacks steal log in information?

A CSRF attack is a blind attack where the attacker can control the request sent to the server, but due to the same origin policy cannot get the contents of the HTTP response. To get the response one would need something like Cross-Site-Scripting or DNS-Rebinding attacks. That's at least the case with the default behavior, but if the target server employs a (non-default) wide open CORS policy reading the response from an CSRF attack using XMLHttpRequest might be possible too.

But one can still cause lots of damage, like changing the DNS settings in a router and from then on effectively be the man in the middle. See How millions of DSL modems were hacked in Brazil....


What can I do to find out who is remotely accessing my PC?

Here are some things which might help:

Turn off/Unplug your router, then boot up your computer.
Open settings and go to Apps & Features, look through the list for programs like 'TeamViewer'. I suggest you google search some top remote access programs and try to identify any you might have installed
Uninstall those you find, and also anything else you don't need. If you don't know what something is, Google the name first to find out.
Go back to the main settings window, and go to System > About. In the Related settings list on the right, select System info.
Click Advanced System settings on the left, and go to the Remote tab
Untick 'Allow Remote Assistance connections to this computer'
Back in the settings main window, open Update & security
Ensure both Windows and Windows Defender are up to date, if they aren't reconnect to the internet and update them.
Run a windows defender scan.

If those steps don't work or you want to be extra sure, you will unfortunately have to Nuke it from orbit, but after doing so I suggest you step back through the above to untick the Windows built in 'Allow Remote Assistance connections to this computer'.


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

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

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

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


The basic difference with a closed system for esignatures is where the esigned document resides.  With SaaS or Cloud based eSigning, the actual esigned document resides on their servers(for some period of time) as they offer the esigning as a service.  You do have methods to retrieve the documents, but "moving" the document from the evault it was originally stored in opens legal questions as to tampering or modifying the document's data.  With a closed system (like the one from my company, eSignSystems) the evault/server that maintains the tamper evident-sealed document (after it is signed) sits behind the customers firewall, not in the cloud.  All security as to access, process and authentication is controlled by the customer.  We believe this ensures a more legally enforeable document should the esignature ever be disputed.


Review of approach to client-side only hashing and encryption for web application

You are going about it wrong.  There is no point at all to a hash for authentication if the comparisons are being done locally because an attacker can simply inject the hash value directly into memory and bypass the authentication check.

For local purposes, you have to use something like your second part of your idea, but that part should be done using existing standards.  What you need is a key derivation function.  A key derivation function is an algorithm that can securely take a password and use it to form an encryption key.  Since the keys that are built are frequently relatively weak, it should be used to encrypt a truly random key which is then used for the actual encryption and decryption of the DB.

Using an encryption based approach, it becomes irrelevant if the user forces a key in to memory because they will be unable to access the encrypted data.  The encryption itself acts as both the authentication and data protection mechanism.  (If you want a way to verify proper decryption, you can always encrypt a known value and check the decryption of that value.)


What are the performance and security tradeoffs when selecting "ECC" or "Subgroup" in a U-Prove token?

U-Prove is a technology which is, roughly, a mix of digital certificates and blind signatures. The Prover has a few "attributes" that the Issuer (i.e. the Certification Authority, more or less) asserts to be true. However, when dealing with any given Verifier, the Prover wants to be able to choose what he shows: namely, he wants to show only some of the attributes. Moreover, when the Prover deals with several distinct Verifiers, the Prover does not wish the Verifiers to be able to correlate their inputs and notice that the same Prover was involved in both cases.

In the specification, the cryptographic algorithms which achieve that are described. Namely, there is a finite group in which all participants play. That group is either a subgroup of the integers modulo a prime p, or an elliptic curve. The group has a size q (in the "subgroup" case, q is necessarily a divider of p-1). Each group element can be represented as a sequence of bytes. The group must be such that discrete logarithm is not feasible.

To give some figures: suppose that we want "112-bit security", i.e. something quite strong by today's and tomorrow's standards. This is a level of resistance which cannot be broken unless the attackers musters enough computing capabilities to perform at least 2112 elementary operations, a figure which is way too high to be economically feasible with today's technology. To get this level of security, the group size will have to be at least 224-bit long (q must be no less than 2223). For the elliptic curve, it will be sufficient to have a "224-bit curve" whose elements can be encoded over a sequence of 225 bits (or 224 bits in some cases, depending on the underlying protocol). On the other hand, when working modulo a prime p, there are known shortcuts for discrete logarithm, so we need a much bigger p, up to about 2048 bits (see this site for a lot of data on the subject). An integer modulo a 2048-bit integer p can be represented as a sequence of 2048 bits.

In that sense, when using the "subgroup" model, group elements used in U-Prove tokens are about 9 times longer than what they would have been if the "elliptic curve" model had been used, for the same level of security. Note, though, that the "9" figure depends on the security level (it is not linear).

A U-Prove token itself contains a number of fields, two of which (the public key h, and a part of the signature σ'z) are group elements. Therefore, for the 112-bit security level, a U-Prove token using a "subgroup" ought to be about 455 bytes longer than a U-Prove token of equivalent security but relying on an elliptic curve. Mind the "ought to": this figure is theoretical; I haven't tried. Encoding peculiarities may change that a bit. Also, a U-Prove token includes other fields which may dwarf this difference, to the point of making it irrelevant. This really depends on the usage context.

As for performance, the text you quote is weird, because, usually, elliptic curves are faster (because they work in a much smaller field). In practical situations involving computers or smartphone, computing costs are usually negligible with regards to I/O (network latency and so on), but when smartcards are involved, the difference can be important. If a given implementation of U-Prove is faster with 2048-bit subgroups than with 224-bit elliptic curves, then that implementation is quite sloppy (as @CodesInChaos says in his comments).

On security: Current state of affairs, with regards to the relative resistance of prime subgroups and elliptic curves, has not changed much in the last 20 years. Best known algorithm for discrete logarithms modulo a big prime p is still a variant of the General Number Field Sieve, and there is no known shortcut for discrete logarithms in elliptic curves.

Although computations in the "subgroup" case are slower and need bigger values than elliptic curves, they are also noticeably simpler to implement, in particular when it comes to thwarting side-channel attacks (e.g. timing attacks). Implementing robust cryptographic primitives is hard; don't do it unless you really must. But if you have to do it yourself, then you will prefer the "subgroup" case.


Why attack detection based on the same user request from different places (e.g. by IP) is not widely used?

There are a few reasons that IPv4 addressing is not used in this way:

IP addresses are not a foolproof indication of location. IP address blocks are assigned to companies and can be used anywhere they are required. A company in Asia may get a block from apnic, but then use part of their allocation in north America
Systems get different IP addresses all the time for legitimate reasons. The user's home ADSL router may be assigned a different address, or the user may log in using WIFI at Starbucks, a change of IP address is not a good indicator of fraud
A user may be using an anonymizer or VPN of some kind. A user logging in with Tor may appear to be coming from a different location entirely
A user may be using more than once device to log in at the same time. Many people use mobile devices at the same time as their laptops, or have a work machine and a personal machine going to the same site

These are all true with IPv4 in which IP addressing is assigned according to the network segment you are on. Using IP address changes to detect fraud will result in too many false positives.

Note that with IPv6 the second half of the address is the MAC address of the device. As MAC addresses are (supposedly) unique it may be viable to do a fraud check when a new machine address is detected logging into an account. This is what companies like Facebook are already trying to do - detecting new systems rather than IPs logging in.


You can prevent command injection which should be done by giving the regex to grep via stdin rather than relying on escapeshellarg() as it has some tricky edge cases like argument injection. You will still be vulnerable to regular expression abuse such as denial of service and can also disclose content of unintended files. Try running grep '' /etc/passwd.
Most search functions work by analysing files/content and building a data store which can be queried. Using grep is a dirty work around and has some.big problems.


Phishing attack stuck with jsp loginAction.do page?

You are trying to do a MITM attack by copying the files from the Google login page? We cannot help you. There are too many variables to consider and then this question becomes far too localized to your situation.

Check out SET for better, more complete methods of doing what you propose, and you will learn far more than the mini-tutorial you linked. Look through the SET code once a fake page is set up and you will learn far more.

For deeper knowledge, flip through The Web Application Hacker's Handbook. It is more detail than you need right now, but is the bible for web application hacking.


Why is the deprecated SSL 2.0 protocol considered insecure and how can it be exploited?

SSL 2.0 is not a vulnerability; it is a protocol which happens to contain structural vulnerabilities, and, as such, should not be allowed.

There is a RFC which says just that, and lists the main known deficiencies in SSL 2.0:

SSL version 2.0 [SSL2] deficiencies include the following:

o  Message authentication uses MD5 [MD5].  Most security-aware users
   have already moved away from any use of MD5 [RFC6151].

o  Handshake messages are not protected.  This permits a man-in-the-
   middle to trick the client into picking a weaker cipher suite than
   it would normally choose.

o  Message integrity and message encryption use the same key, which
   is a problem if the client and server negotiate a weak encryption
   algorithm.

o  Sessions can be easily terminated.  A man-in-the-middle can easily
   insert a TCP FIN to close the session, and the peer is unable to
   determine whether or not it was a legitimate end of the session.

Of the four, only the last one is really a structural serious issue with the protocol. Indeed:

Though MD5 is broken with regards to collisions, it is still quite strong for other usages, including how it is used in SSL 2.0 to protect integrity.
When an attacker tricks client and server to use a weak cipher suite, the real problem is not that the attacker can trick the client and the server; it is that the client and server actually agree to use a weak cipher suite.
The point about using the same key for encryption and integrity makes sense, again, only if the client and server agree to use weak encryption. This could happen in older days because of compliance with the US export regulations, but this has all disappeared since year 2000.
The lack of verified termination is a problem when the SSL is used to convey a protocol where messages are not self-terminated. A typical case is HTTP 0.9: the client knows that it has obtained the complete file because the server closes the connection. With SSL 2.0, an active attacker can force an early connection close and the client has no way to know whether this is the genuine end-of-file, or a malicious truncate.

One may argue that with modern HTTP, this issue no longer applies.

So, in fact, if a client and server use SSL 2.0 right now (May 2014), then chances are that this is not an actual problem (or, at least, not the biggest security problem). The real reason why SSL 2.0 is banned is that it has been deprecated for a long time (since 1996 and the invention of SSL 3.0), so any use of SSL 2.0 indicates that some of the involved software has not been updated for at least that long -- and that is a problem. SSL 2.0 is a glorified canary.

Or, said otherwise, using or even allowing SSL 2.0 reveals you as a sloppy, outdated, untrendy sysadmin.


is this code valid for securing passwords?

This is not secure. You have only 2 rounds of SHA-512, which is not computationally complex. Your salt is also a variable length (between 0 and getrandmax() bytes), which means storage will be unreasonably large (an average of 16 kilobytes of storage for each password?!).

Please do not attempt to create your own password storage system. Use one of the proven solutions: PHPass, bcrypt, PBKDF2, or scrypt


For TLS how to instruct IIS 7 to include Intermediate CAs to be included in the Certificate Request frame?

It's possible to work around the somewhat liberal IIS interpretation of the SSL/TLS spec by exporting your client certificate in PEM format (base64 ASCII), appending the public certificates for the CAs in the trust chain, and then importing the certificate back into the keystore under the same alias.

To clarify: it's not enough to have all the certificates in the chain in the keystore - they have to be imported with the client certificate itself as a bundle. See this thread at StackOverflow for details: why doesn't java send the client certificate during SSL handshake?

I've just used this method to resolve this exact issue with a Java client and an IIS 7.5 server.

EDIT:

Note that after you import the certificate in bundle form (with its CAs) you won't notice any new entries with keytool -list. Also, if you export the alias again, you'll still only get the client certificate itself. The only difference you'll notice is an extra couple of KB on the file.

Use a tool like KeyStore Explorer to see all of the certificates associated with a keystore entry. In fact, KeyStore Explorer also lets you append certificates to the in-keystore certificate chain for any entry, as an alternative to the export/edit/import route.


Is this a demonstration that the shellshock patch isn't working?

You are having bash execute the commands separated by ';' in turn.  This is normal behavior and not an indicator that the bug's patch is inadequate.


How to know if a host has been compromised and re-secure it again? (particular case of a raspberry)

It is impossible to prove that an attacker has not compromised your server.  It is always possible that an attacker accessed and installed malware that would be left behind.

The safest thing to do is to reinstall the OS.  This is the only way you can truly know that it is an uncompromised OS.  The password for the account should be changed so with public access an attacker could not login.

From looking at my system logs, my server gets about 1000 bad logins per day with most using the username root, but some using pi.


Where to start with api security testing?

Tips to ensure that your APIs are fully security tested :

Automate: Most of the testing approaches for security vulnerabilities that we have covered can be automated (here’s a tool to help you do so); and should definitely be done so – preferably against your production environment in some way. A system upgrade or server reconfiguration could be just as much a cause for a security vulnerability as bad development in the code of your APIs – and you definitely want to find out if such changes open up for unexpected vulnerabilities before anyone else.

Stay on top: OWASP provides invaluable services and information on Internet related security vulnerabilities – and how to work against them. Make it a habit to check out their website and match their recommendations and findings against your APIs and infrastructure. Follow their guidelines – specifically those geared at APIs – and make sure you are doing what you can base on their resources.

Finally – It’s your problem: Security is probably not going to be fixed or worried by anyone else than you, – make sure you give it the same attention and focus as you do to functional, performance, usability, A/B testing, etc. The price to pay for leaked passwords or erased user data is too high to pay for you not to care (which I know you do).

Visit this, page it tell you how you can do security check on your API's


I will answer your question in two parts:

  The communication channel should be encrypted with RSA. How can I do that?

RSA is really slow to encrypt whole messages. The usual way this is done is to encrypt the message with a symmetric cipher like AES, then encrypt the symmetric key using the recipient's RSA public key.

Having said that, there are a lot of small details to get right, so I would advise you to use a pre-built implementation. In fact, just use SSL/TLS, use-cases like yours are exactly what it's made for. OpenSSL in the most common TLS implementation, it's easy to use and will take care of all the crypto for you. Googling something like "introduction to openssl programming" should get you started.

EDIT: As @Volker pointed out in comments, many common instant messenger clients like Pidgin and Kopete use the library Off-the-Record Messaging which is an encryption protocol specifically designed for instant messengers. OTR uses PGP as the underlying encryption system. There is an OTR library for C available here, and a Java library here.

Now for the second part of your question:

  Generate keypairs on every client and when a client tries to communicate, ask for public key? It is this safe?

Let the SSL/TLS handshake take care of all this. It uses a key-exchange protocol called Diffie-Hellman which solves the key-exchange problem quite nicely.

One thing you will want to think about is whether you need strong authentication, ie whether or not you're worried about people impersonating other users. If so, you'll need to get everybody's public keys made into certificates that ties each public key to a specific person. This is a much more complicated setup that will require some sort of Public Key Infrastructure - either you'll have to setup a Certificate Authority server (you can do it with OpenSSL), or have a web-of-trust system like PGP does. If you do decide to go this route, you can find info on Google, on this exchange, or you can post new question(s) about setting up a PKI for your chat network.


Create memory dump from the windows commandline

For doing a memory dump, you can use DumpIt and read the dump with volatility.


Is there an index of all md5 collisions?

See this page for a downloadable implementation of a generator of MD5 collisions, using Klima's method. On a Core2 2.4 GHz CPU, it produces on average one collision every 14 seconds (and that's using only one core; since the research entirely fits L1 cache, it scales optimally on multi-core CPU). I let it run a few weeks, and measured that over more than 100000 collisions.

So no, there's no index of all MD5 collisions. You'd better use a robust hash function. Try SHA-256 first; it is the usual recommendation. If (and only if) you hit an actual, measured performance issue with SHA-256, then you might look for alternate functions (a 2.4 GHZ Core2 CPU could still hash a few millions file names per second, so it takes a rather special situation for SHA-256 to actually have performance issues).


The private keys are not displayed, not even ephemeral ones used only for that session.
But public keys are displayed. Person with access to output of ssh -vvv would be able to identify the server in an internet scan (if server is open to the internet) and identify the client using something like "ssh public key is associated with github account".
So this is a privacy problem, but not a way to attack the server or the client, IMO.
If an insecure authentication method is enabled, even if it is not used, person with access to output would see that, and might try to attack the server or the client using that insecure method. There are tools to scan servers (e.g. this) but the information about the configuration of the client is new to the attacker. The attacker might get the same information by MiTM or by tricking client to try to connect to it without pretending to be something else.


Risks of allowing users to upload PDF and XML files to be stored/retrieved from a DB (ASPNET MVC 5)

Good moves to check XML for the correct schema, make sure you disable DTD as well and never allow a user input to modify XML schema, for that could result in a deserialization vulnerability.
https://docs.microsoft.com/en-us/visualstudio/code-quality/ca3075-insecure-dtd-processing?view=vs-2019

A potential vector could be, that the PDF content itself contains malicious stuff, but it is something you really can't avoid, because it is in the users control.


Clarification of details regarding an SSL Stripping Attack

Your understanding is correct.

This is because the attacker established the HTTPS communication, so when the response from the web server comes to them it is decrypted and then forwarded to the victim.
Yes, all HTTPS links in the body are replaced with HTTP links, as the Location header.
sslstrip analyses the response headers and

removes accept-encoding

I think this is so the attacker doesn't have to decompress and recompress every request from the client when analysing requests.
removes if-modified-since

This is so the client has to make a full request to the server, even if the page hasn't been modified. This header needs to be removed because otherwise there is no complete request to the server and nothing to intercept.
removes cache-control

This is for the same reason as if-modified-since, so the client doesn't try to load the page from a cache and avoid making a complete request to the request to the server.
changes link in Location header to HTTP


How to verify the signature of DHE_RSA server parameters (TLS 1.2)?

For TLS 1.2 the signature should be over the two hello nonces plus the ServerDHParams portion of the ServerKeyExchange message. See rfc5246 section 7.4.3 which shows the input to the digitally-signed construct from section 4.7.

But note earlier protocol versions are different for RSA signature. Two hashes, MD5 and SHA1, are concatenated, but are NOT encoded as an ASN.1 SEQUENCE with the AlgorithmIdentifier for the hash per section 10 of PKCS#1v1.5; instead they are directly formatted as block type 01 per section 8.1 (and modexp'ed in the usual way per 8.2-8.4). This is equivalent to omitting step 2 of EMSA-PKCS1-v1_5 in PKCS#1v2, although rfc4346 4.7 et pred are not totally clear about it.

ADDED in response to comment: what you described should indeed work; here is an example/demo using data from openssl s_client -msg:

>>> TLS 1.2 Handshake [length 00f2], ClientHello
    01 00 00 ee 03 03[57 20 2e 6d bc af 8f 40 58 f4
    0f bd 82 82 dc 78 00 36 2a 74 88 0b 14 71 ef f6
    65 45 db 1f 62 e8]00 00 84 c0 30 c0 2c c0 28 c0
    24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
    38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
    05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
    23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00
    32 c0 12 c0 08 00 9a 00 99 00 45 00 44 00 16 00
    13 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 c0 0d c0
    03 00 9c 00 3c 00 2f 00 96 00 41 00 0a 00 07 c0
    11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00
    41 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
    19 00 18 00 17 00 23 00 00 00 0d 00 20 00 1e 06
    01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04
    03 03 01 03 02 03 03 02 01 02 02 02 03 00 0f 00
    01 01
<<< TLS 1.2 Handshake [length 0051], ServerHello
    02 00 00 4d 03 03[57 20 2e 9a fe 0a b0 e9 cb 39
    75 23 03 05 52 4a 5a ab a1 2d 59 5e 57 86 ea 98
    98 52 2c e8 40 30]20 57 20 2e 9a 5e 4d 19 0d 1d
    17 5b 62 ef 83 7a 5c 83 a0 03 51 fa a7 2d 60 69
    bc 9c 2b b6 8c 37 c3 00 9f 00 00 05 ff 01 00 01
    00
<<< TLS 1.2 Handshake [length 01ab], Certificate
    0b 00 01 a7 00 01 a4 00 01 a1 30 82 01 9d 30 82
    01 06 a0 03 02 01 02 02 04 57 20 2e 12 30 0d 06
    09 2a 86 48 86 f7 0d 01 01 05 05 00 30 13 31 11
    30 0f 06 03 55 04 03 13 08 74 65 73 74 63 65 72
    74 30 1e 17 0d 31 36 30 34 32 37 30 33 31 32 31
    38 5a 17 0d 32 36 30 34 33 30 30 33 31 32 31 38
    5a 30 13 31 11 30 0f 06 03 55 04 03 13 08 74 65
    73 74 63 65 72 74[30 81 9f 30 0d 06 09 2a 86 48 \
    86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02
    81 81 00 f1 f7 68 e8 f9 da 82 eb cd b6 bf 41 e8
    48 35 dc a4 18 3f e7 cf 4c 73 6f 9d c8 d0 1e 01
    15 4c 60 88 87 22 dd f2 a0 8c b0 27 55 e0 10 bc signing key
    e7 d6 37 c0 58 27 a9 7b 06 7e 0b 99 f8 ac c2 32 (in cert)
    8c d2 2a 46 74 a4 ef 27 1e f6 65 86 6e ca fe 34
    23 d5 21 fc d7 ab 05 2b 3e ed ba c8 44 24 36 0e
    8c f9 d6 d7 55 1c 56 09 ff 6f 0d 7e 08 4c 7a 59
    cf c6 f3 f9 47 6a 58 69 b3 08 7f 35 e6 6e f9 2d
    c4 02 0d 02 03 01 00 01]30 0d 06 09 2a 86 48 86 /
    f7 0d 01 01 05 05 00 03 81 81 00 be ba ea d9 11
    24 f9 b9 02 c8 35 e3 11 b6 00 0c 46 b1 ed 5a b5
    2b 0c b1 b5 ed 71 da 2c 25 e1 9c 7a 73 40 3d 91
    2b 45 9f 62 ef 43 15 fe 4f 46 a1 55 74 2f 4c 5d
    a5 69 0a 0e 39 e2 5e 03 49 b5 6e 34 21 cd 2f d1
    fa ec 6b 2f 10 32 25 6d e3 8b b4 d8 b7 86 25 59
    f7 86 be 1e dd cf cd 16 10 3f b7 78 4e 42 45 aa
    fa 58 0a c4 1d 52 fe a5 61 64 4b e5 55 8d de 36
    02 f1 d2 19 cd be ca 4a 93 2e 76
depth=0 CN = testcert
verify error:num=18:self signed certificate
verify return:1
<<< TLS 1.2 Handshake [length 020e], ServerKeyExchange
    0c 00 02 0a[00 80 fd 7f 53 81 1d 75 12 29 52 df \
    4a 9c 2e ec e4 e7 f6 11 b7 52 3c ef 44 00 c3 1e
    3f 80 b6 51 26 69 45 5d 40 22 51 fb 59 3d 8d 58
    fa bf c5 f5 ba 30 f6 cb 9b 55 6c d7 81 3b 80 1d
    34 6f f2 66 60 b7 6b 99 50 a5 a4 9f 9f e8 04 7b P
    10 22 c2 4f bb a9 d7 fe b7 c6 1b f8 3b 57 e7 c6
    a8 a6 15 0f 04 fb 83 f6 d3 c5 1e c3 02 35 54 13
    5a 16 91 32 f6 75 f3 ae 2b 61 d7 2a ef f2 22 03
    19 9d d1 48 01 c7 00 80 f7 e1 a0 85 d6 9b 3d de -
    cb bc ab 5c 36 b8 57 b9 79 94 af bb fa 3a ea 82
    f9 57 4c 0b 3d 07 82 67 51 59 57 8e ba d4 59 4f
    e6 71 07 10 81 80 b4 49 16 71 23 e8 4c 28 16 13
    b7 cf 09 32 8c c8 a6 e1 3c 16 7a 8b 54 7c 8d 28 G
    e0 a3 ae 1e 2b b3 a6 75 91 6e a3 7f 0b fa 21 35
    62 f1 fb 62 7a 01 24 3b cc a4 f1 be a8 51 90 89
    a8 83 df e1 5a e5 9f 06 92 8b 66 5e 80 7b 55 25
    64 01 4c 3b fe cf 49 2a 00 80 8c 75 b3 17 44 2c -
    a0 0d 45 3d e9 d3 18 f1 d9 a2 88 85 66 01 4e 86
    e3 46 57 3d d7 64 3a cd c4 d3 14 d5 a3 27 1c 62
    7e c3 23 8a 16 b9 0c 1f 48 f6 c6 8b 2a 6d 36 35
    d7 d9 38 0a 89 cb 88 db 52 ce 3e 5d b4 b6 2a 33 Y
    aa b6 1f 0d 09 14 a5 4e 20 7e 4c 61 6d 22 71 7d
    da fc e7 3b 49 80 31 3d d6 e3 d1 75 a9 69 48 6b
    54 74 27 23 4f 95 63 a2 55 5f 8d da 66 9b 8f 49
    2a 21 0b 1d 31 21 b3 60 aa 0c]06 01 00 80[94 fa -
    c9 33 1e 8c 4c 9c 91 47 a4 52 2e 5a 91 a6 2b 99
    6b 4b 1d 33 1f 9a 9c 44 cc f4 47 9e 3a 7a 70 40
    ff b6 bd 23 0b 51 8b 5c 9a 9e 6d 69 a7 f6 a0 65 signature
    ca 4a 3b 49 46 34 bb 1a 7c 4e c3 5f e0 fc b3 d1
    1f 03 c0 f0 2e f4 87 23 75 3f d5 bc 56 82 4f 83
    f9 b2 da 41 b9 68 b9 33 af 0a ed 4d c2 d8 f0 4d
    2c 21 ad d3 5d 76 47 2f cc 8e 29 72 e5 d6 96 ec
    6d 96 2a c5 80 eb 7c cf 1b ea f6 66 fb fc]      /
<<< TLS 1.2 Handshake [length 0004], ServerHelloDone
    0e 00 00 00

Step 1: concatentate the marked pieces and hash

[dthomps@virt2 ~]$ cat temp1
                      57 20 2e 6d bc af 8f 40 58 f4
    0f bd 82 82 dc 78 00 36 2a 74 88 0b 14 71 ef f6
    65 45 db 1f 62 e8
                      57 20 2e 9a fe 0a b0 e9 cb 39
    75 23 03 05 52 4a 5a ab a1 2d 59 5e 57 86 ea 98
    98 52 2c e8 40 30
                00 80 fd 7f 53 81 1d 75 12 29 52 df
    4a 9c 2e ec e4 e7 f6 11 b7 52 3c ef 44 00 c3 1e
    3f 80 b6 51 26 69 45 5d 40 22 51 fb 59 3d 8d 58
    fa bf c5 f5 ba 30 f6 cb 9b 55 6c d7 81 3b 80 1d
    34 6f f2 66 60 b7 6b 99 50 a5 a4 9f 9f e8 04 7b
    10 22 c2 4f bb a9 d7 fe b7 c6 1b f8 3b 57 e7 c6
    a8 a6 15 0f 04 fb 83 f6 d3 c5 1e c3 02 35 54 13
    5a 16 91 32 f6 75 f3 ae 2b 61 d7 2a ef f2 22 03
    19 9d d1 48 01 c7 00 80 f7 e1 a0 85 d6 9b 3d de
    cb bc ab 5c 36 b8 57 b9 79 94 af bb fa 3a ea 82
    f9 57 4c 0b 3d 07 82 67 51 59 57 8e ba d4 59 4f
    e6 71 07 10 81 80 b4 49 16 71 23 e8 4c 28 16 13
    b7 cf 09 32 8c c8 a6 e1 3c 16 7a 8b 54 7c 8d 28
    e0 a3 ae 1e 2b b3 a6 75 91 6e a3 7f 0b fa 21 35
    62 f1 fb 62 7a 01 24 3b cc a4 f1 be a8 51 90 89
    a8 83 df e1 5a e5 9f 06 92 8b 66 5e 80 7b 55 25
    64 01 4c 3b fe cf 49 2a 00 80 8c 75 b3 17 44 2c
    a0 0d 45 3d e9 d3 18 f1 d9 a2 88 85 66 01 4e 86
    e3 46 57 3d d7 64 3a cd c4 d3 14 d5 a3 27 1c 62
    7e c3 23 8a 16 b9 0c 1f 48 f6 c6 8b 2a 6d 36 35
    d7 d9 38 0a 89 cb 88 db 52 ce 3e 5d b4 b6 2a 33
    aa b6 1f 0d 09 14 a5 4e 20 7e 4c 61 6d 22 71 7d
    da fc e7 3b 49 80 31 3d d6 e3 d1 75 a9 69 48 6b
    54 74 27 23 4f 95 63 a2 55 5f 8d da 66 9b 8f 49
    2a 21 0b 1d 31 21 b3 60 aa 0c
[dthomps@virt2 ~]$ xxd -r -p temp1 | openssl sha512
(stdin)= 3338170798d1c811b121fcdf6fa7f4292807f68cdb3e4b7817d91c0f5ac427e7b4b3871c99685e0f783362d0c9c564b5dcf9725b3949532b8870ca6fb93b3c8e

Step 2: get publickey into usable form

[dthomps@virt2 ~]$ cat tempk
                      30 81 9f 30 0d 06 09 2a 86 48
    86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02
    81 81 00 f1 f7 68 e8 f9 da 82 eb cd b6 bf 41 e8
    48 35 dc a4 18 3f e7 cf 4c 73 6f 9d c8 d0 1e 01
    15 4c 60 88 87 22 dd f2 a0 8c b0 27 55 e0 10 bc
    e7 d6 37 c0 58 27 a9 7b 06 7e 0b 99 f8 ac c2 32
    8c d2 2a 46 74 a4 ef 27 1e f6 65 86 6e ca fe 34
    23 d5 21 fc d7 ab 05 2b 3e ed ba c8 44 24 36 0e
    8c f9 d6 d7 55 1c 56 09 ff 6f 0d 7e 08 4c 7a 59
    cf c6 f3 f9 47 6a 58 69 b3 08 7f 35 e6 6e f9 2d
    c4 02 0d 02 03 01 00 01
[dthomps@virt2 ~]$ xxd -r -p tempk |openssl rsa -inform d -pubin >tempk.pem
writing RSA key

Step 3: "verify-with-recovery" the signature value

[dthomps@virt2 ~]$ cat temp2
                                              94 fa
    c9 33 1e 8c 4c 9c 91 47 a4 52 2e 5a 91 a6 2b 99
    6b 4b 1d 33 1f 9a 9c 44 cc f4 47 9e 3a 7a 70 40
    ff b6 bd 23 0b 51 8b 5c 9a 9e 6d 69 a7 f6 a0 65
    ca 4a 3b 49 46 34 bb 1a 7c 4e c3 5f e0 fc b3 d1
    1f 03 c0 f0 2e f4 87 23 75 3f d5 bc 56 82 4f 83
    f9 b2 da 41 b9 68 b9 33 af 0a ed 4d c2 d8 f0 4d
    2c 21 ad d3 5d 76 47 2f cc 8e 29 72 e5 d6 96 ec
    6d 96 2a c5 80 eb 7c cf 1b ea f6 66 fb fc
[dthomps@virt2 ~]$ xxd -r -p temp2 | openssl rsautl -verify -inkey tempk.pem -pubin -pkcs |xxd -p
3051300d0609608648016503040203050004403338170798d1c811b121fc
df6fa7f4292807f68cdb3e4b7817d91c0f5ac427e7b4b3871c99685e0f78
3362d0c9c564b5dcf9725b3949532b8870ca6fb93b3c8e

which parses as

3051 = SEQUENCE OF
300d06096086480165030402030500 = AlgId for sha512
0440 = OCTET STRING containing
3338170798d1c811b121fc
df6fa7f4292807f68cdb3e4b7817d91c0f5ac427e7b4b3871c99685e0f78
3362d0c9c564b5dcf9725b3949532b8870ca6fb93b3c8e
= the hash value above


Secure communication between C# client and Java server, using certificates

I suggest that you use a SSL/TLS library for C# (SslStream? OpenSSL? ask on Stack Overflow if you want more recommendations) or Java (SslSocket? BouncyCastle? ask on Stack Overflow if you want more recommendations).

You can use TLS to encrypt the entire communication.  As @ordag says, don't try to invent something on your own.  This is tricky stuff.  TLS has been carefully vetted, and there are many existing implementations, so it will be pretty easy to use.

As @symcbean says, you can easily create your own self-signed certificates (e.g., with OpenSSL), which should fine for your purposes.

Read the following questions, too: What's the difference between SSL, TLS, and HTTPS?, Best tool for testing an SSL connection in my application.


Apple FileVault -- would Apple build a backdoor?

I would be less worried about a backdoor than sheer weakness as an encryption scheme. This article appeared in February this year and was the first thing that came up when I typed "decrypt filevault" in google:  http://reviews.cnet.com/8301-13727_7-57369983-263/filevault-2-easily-decrypted-warns-passware/

You should check out TrueCrypt, as they are evidently purely devoted to mac disk encryption. Probably any non-costly or self-made system will be reversible in the right hands, partly due to the fact that the decrpyter would be smart to assume one of those methods (free or supplied with the operating system) were used, which is essentially removing one variable in the search for the decryption key.


Yes, it could be a disadvantage. What is boils down to is how much you trust the VPN provider.

For most secure protocols, using a VPN will be just as secure because your communications are encrypted by the protocol. If there was a MITM at the other end of the VPN connection they would not be able to do much (apart from a side channel attack, which are usually pretty useless in isolation). Of course, this is assuming the protocols and software are secure, and cannot be not affected by the FREAK attack or other downgrade attacks.

However, the web is different. The main issue is that the Same Origin Policy does not designate a different origin for plain vs encrypted where cookies are concerned. A cookie set on http://example.com can be read by https://example.com. If there are any cookie handling vulnerabilities on the site then the "secure" connection could be compromised. The Secure Flag does not help here - this only prevents a plain HTTP connection from reading a cookie set over HTTPS, not the other way round. An example could be cookie poisoning like session fixation, or if there's an XSS vulnerability based on a cookie value that was assumed to only have been set via HTTPS. These are really vulnerabilities on the sites themselves, however using an untrusted connection allows them to be exploited.

So if there is any doubt about the trust of your VPN provider, then disable plain HTTP from your browser and use the internet over HTTPS only. You can do this by setting an invalid proxy server for plain HTTP (e.g. 127.0.0.1:8).

Of course, you should make sure you are using a secure protocol for your VPN connection too (e.g. not MS PPTP). Also, make sure you use iptables/Windows Firewall properly to prevent any incoming connections to your machine whilst connected to the VPN.


Filtering out JavaScript from HTML to prevent XSS?

Filtering out JavaScript from HTML is a very complicated thing to do, especially if you cant restrict the allowed tags and attributes to a small set (or, preferably, none). To get this right is suprisingly complicated and there are many pitfalls. One mistake is all it takes to be vulnerable.

So don't go about this on your own. Use an existing, tried and tested library. For PHP HTML Purifier is a popular one, but I am sure there are more options out there.

In addition, you should use a restrictive content security policy if possible. But don't rely on that as your only line of defence.


Why are files that are not assigned to a user considered a security risk?

On a Linux system you can easily delete a user without having to delete any files owned by that user. Such a file will stay in place and the file owner's user ID (which is stored as an attribute of the inode) remains unchanged. This way a file can become effectively ownerless.

If you then later create a user with the same ID, the user will automatically become the owner of the previously orphaned files. That's how a new user may unintentionally (or with malicious intent) become the owner of files they shouldn't own, which is obviously bad for security.

Note that userdel has an extra switch to remove users along with their files, but it will only remove the files from some fixed locations, such as the home directory:

 -r, --remove
       Files in the user's home directory will be removed along with
       the home directory itself and the user's mail spool. Files
       located in other file systems will have to be searched for
       and deleted manually.

You may want to use find with the -nouser switch to discover files with a non-existent owner:

 -nouser
    No user corresponds to file's numeric user ID.

Here is a quick demo on Arch Linux.

Let's add a user alice and make her the owner of a file foo.

[root@box /]# useradd alice
[root@box /]# touch foo
[root@box /]# chown alice foo
[root@box /]# ls -l foo
-rw-r--r-- 1 alice root 0 Jan  5 02:59 foo

Now let's delete alice.

[root@box /]# userdel alice
[root@box /]# ls -l foo
-rw-r--r-- 1 1001 root 0 Jan  5 02:59 foo

ls can't determine the owner name and just displays the numeric owner ID 1001. Now let's add a new user bob.

[root@box /]# useradd bob
[root@box /]# ls -l foo
-rw-r--r-- 1 bob root 0 Jan  5 02:59 foo

Since bob has been assigned the next free user ID, he's now automatically the owner of the file.


Can I get a virus from connecting to a WiFi network?

Depends on your OS and a lot of variables but in general yes.

Because the attacker may perform a man in the middle attack on a poorly designed update mechanism (not windows update) and or (again depending on your setup) abuse windows' local features like printer sharing as an attack vector.

As with everything there is no 100% solution but a very good start is using a VPN in order to fully encrypt all in/outgoing traffic and verify its integrity.


Is this some sort of scam or do I have stalker?

This appears to be coming from one or more scammers. By analyzing the mail headers it reveals the IP address: 67.4.235.234

In addition to that, it seems some internal information is disclosed from the sender: 3capp-mailcom-lxa15.server.lan

http://mxtoolbox.com/Public/Tools/EmailHeaders.aspx?huid=a56c17eb-26ce-4d53-b030-e9f1a1447fec

By searching for this internal information disclosure, it revealed that this QWest customer is sending the emails (although it could be a compromised machine) and are found on scammer sites:

Performing a WHOIS lookup on the IP address an abuse email address with instructions on how to send an abuse complaint is found:

I suggest to fill out all the details that they want, including the mail headers (yes, multiple headers) and send a complaint to abuse@centurylinkservices.net

In addition, you could send them the link to this topic so they can see this analysis.

Hope this helps and good luck!


Some of the services offered (not especially by McAfee, but in general in this area):

checking the site is up
confirming the DNS records are correct
scanning email in and outbound
running your intrusion detection service
checking for spoof/malicious versions hosted elsewhere
checking for brand theft
checking your versions of OS/app etc against new advisories
scanning for common vulnerabilities
many others

Of course, all of these are something you can do yourself, given a large enough pool of skilled staff (eg IDS requires far more humans than you might expect) - so what a lot of organisations do is assess all of these against their infrastructure and skill set and what often happens is something like the following:

outsource IDS, email scanning, perimeter antivirus and vulnerability scanning (this is very common - the big players do this globally so have rapid response across all clients when something bad is spotted at one)
outsource brand squatting, website spoofing
run detailed exploitation pen tests in house, or outsourced to specialists
some run an in house asset/vuln tracker - some outsource

You need to work out how much each of these would cost you, how much an external provider can do it for, and how important it is in your risk management/mitigation scheme.


Why does my rundll32.exe not have a verified signature?

It appears this is a pretty simple thing.  Windows builtin files aren't individually signed and stored in the binary, they use catalogs to store their signatures.  See here: (it's old but mostly still true: https://blog.didierstevens.com/2008/01/11/the-case-of-the-missing-digital-signatures-tab/)

You can verify this yourself with a quick signature check of the relevant files:

You should also be able to use signtool to verify the catalog, which I'm not sure which is used for rundll32.exe.

signtoolverify /c fileIdontknow.cat rundll32.exe

That should tell you if the catalog contains it, though I'm guessing it should.


You need network access to the other machine ...

This can be accomplished in a few ways (port mirroring on the switch, flooding the switch's MAC table so it becomes a hub, ARP spoofing the target, etc.), but the real answer is that you either need to install Wireshark (or tshark) on the target machine, or get a machine with Wireshark closer to your target's traffic.


No Clonezilla is not a Forensic tool. Even using it for incident analysis is not recommended. Can it be useful, yes, but there are better free tools available for forensic and incident analysis.
Yes RAW filesystem is important. It's where all the deleted files and fragments exist.


Could a private key from JavaScript WebCrypto resist a malware attack?

Extremely intelligent malware with root permissions (on a *nix client) can do just about anything, including redirecting /dev/random or /dev/urandom to something they control.  If the malware can control the random number generation your computer uses to create TLS keys, then it can break the HTTPS communication.

If the browser is open and the user logged in, then malware with the ability to perform raw mem dumps would be able to find the key.

In short, if a user can do it, then a theoretical malware program can do it.

I suggest the question should not be is it possible for malware to... as malware with unrestricted power can do anything that you can do.  Instead, the question is, what would it take for malware to...?  From this perspective, we're not measuring what's possible, but what is probable.

The methodology you described sounds about as good as it can get (outside of using the user's password to lock the private key / shared secret so that the server doesn't have to receive, store, and transmit it).  There is no such thing as perfect security.


Meterpreter pivot with a bind_named_pipe

If you are using Meterpreter, you can set up port forwarding (or even routing) through your existing sessions. Then, when you want to connect to another host on that network, you can point your multi/handler at the tunnel entrance or route.


How does duqu implement its dll files in PNF file format?

As SteveS said in the comments, Windows doesn't care what file name you use - it's just a label. The "file extension" is only used as an indicator for how a user can interact with the file. Many applications also use it as a way to indicate that the file is of a particular type, but ultimately it's nothing more than a naming convention and shouldn't be relied on.

As long as the file is a PE format module, it can be loaded into a process as a module, e.g. via kernel32.dll!LoadLibrary. In fact, Windows relies on this behaviour in many cases, since .exe, .dll, .cpl, .ocx, .sys, .scr and .drv files are all PE files.


Windows Defender Network Protection component really aggressive, what to do?

Forgot about this question.

For anyone reading it, apparently, the whitelist/blacklist functionnality is only available in MDATP (Microsoft Defender Advanced Threat Protection), which requires a Windows 10 E5 licence (at least) to access. This comes from a Microsoft Support Engineer I worked with and to who I asked about this.

So as of today, the only options for Network Protection is Windows Defender via SCCM, PowerShell, GPO and Intune is: Block (Enabled), Audit (Enabled) and Disable (Disabled).


wordpress server visitor log contains a script, what's the risk?

It should be safe to click (although I still wouldn't).

It looks like the attacker tried to exploit the shellshock vulnerability. If your server is vulnerable, the script will already be executed, you calling it again doesn't add that much harm (in this case, you don't have any more rights than the attacker has, assuming you are not viewing the log from the server).

Of course, clicking the link doesn't gain you any knowledge either, and generally, it's a bad idea to click on links in your log (because of XSS), so don't click on it, and check if you are vulnerable to shellshock.


Why does the ★-property rule of the Bell-LaPadula Model allow information to be stored in objects with HIGHER sensitivity labels?

Sure.  Here's an example.  Suppose we want to have a system log manager, which collects logs from all processes.  We'll run the log manager at system HIGH.  We want every process to be able to send log records to it.

With your proposed rule, processes running at LOW would not be able to send log entries to the log manager.
In contrast, the ★-property allows all processes to send log entries to the log manager.

As far as a practical example, well, Bell-Lapadula isn't very practical.  If you're looking primarily for practical stuff, I wouldn't spend your time looking at Bell-Lapadula; I'd recommend looking at more recent work on systems security -- it'll be a better use of your limited time.


What is the DUKPT Key Derivation Function?

It basically works like this: the server has a master key (the BDK) and each client device has a unique serial number and a counter (which when combined are the KSN).

To set up a new device you encrypt the KSN using the master key (the BDK, the process described in the link in Yoav's answer) and you get a new key (the IPEK). It's kind of like where you need two people (the server and the client) with two keys (the BDK and the KSN) to open a vault that contains another key. That other key is the IPEK and is what you install on the device itself.

The client device uses the IPEK to come up with a table of Future Keys and then discards the IPEK. So the client device now has it's original serial number, a counter (combined are the KSN) and a list of Future Keys.

To encrypt the data, the client device grabs the first Future Key from the list and uses that as the encryption key. It then sends the encrypted data and it's KSN (which contains the  counter) to the server.

On the server end, the server knows it's own secret (the BDK) and now has the clent device's KSN. The server uses those two keys to produce the IPEK (open that vault again). With the IPEK the server can recreate the table of Future Keys and knowing the counter provided by the client (the last 5 characters of the KSN) it knows which key from the table to use.

As for all the technical details I would suggest looking around Andy Orrock's blog (linked to in Yoav's answer) and maybe getting a copy of ANSI X9.24 which has the full spec.


Impact of using map APIs without SSL support?

All things being equal, SSL doesn't directly impact the security of your server. SSL is not a protection layer around your server. It's a protection layer around the communication between the server and the client.

If your application needs to authenticate with the map APIs, then the lack of SSL exposes the authentication credentials to eavesdroppers between your application and the map provider.

The lack of SSL also means that you can't be sure that the data you're receiving from the API providers is genuine. An active attacker (man-in-the-middle) can substitute the data in transit or impersonate the map provider altogether.

If the data is going from the map providers from your server, then in practice, this is not a major concern: only backbone ISPs can attack in this scenario. The entities that are in a position to intercept communications between datacenters are also in a position to plant spies directly inside datacenters and service providers.

If the data is going directly between your application's clients and the map providers, this significantly increases the exposure due to the lack of SSL. Desktop users are frequently in a position where their traffic can be intercepted by anyone nearby (wifi), by an employer, school, hotspot provider, etc. Offering at least the ability to use SSL would be strongly recommended.

Regardless of whether the map data providers support SSL, you should support SSL for the communication between your servers and your clients. Certificates are cheap, and HTTPS is easy to set up for most applications.


Is it okay to have your SSL cert showing when server is reached by IP?

The certificate does not show only when you access by IP. On Firefox, if you click on the padlock icon and show more information, you can get the certificate of the site you are accessing. It's public information, so no need to protect it.

  Is it okay to have your website like Microsoft's that displays the cert in its entirety?

The certificate does not contain the private key, only the public key. Otherwise there would be no security at all in implementing a certificate.

  If someone gets your certificate can't they spoof your websites?

No, the attacker needs the private key of the certificate too. The certificate only contains the public key, the private key is stored on the server, usually on a very special appliance (the Hardware Security Module - HSM).

  Shouldn't you be implementing some sort of redirect for IP addresses like a 301 or something?

Very, very few people will ever try to access Google or Yahoo or whatever using the IP, and usually certificates are not issued for IP addresses. So it's an exception so rare that does not really need to be addressed.