Blind SQL Injection using OOB DNS Practical Sniffing Help

Interesting video.
In my opinion, to setup this kind on technique, you need to:

Own a domain name, say mysite.com
Each domain name has an "Authoritative name server". Usually the Authoritative name server are managed by the company that sold you the domain name.
You need to setup you own Authoritative DNS server on a public IP address, then ask the company that sold you the domain name to set your DNS server as the Authoritative name server for your domain.
Now you own the DNS server that will respond to the DNS query made by this supposedly vulnerable website/application
Due to the fact that you own the DNS server you can simply log all the DNS request, that will contain your data.
Or maybe you prefer to setup a sniffer, like Wireshark, on the DNS server, to just sniff the DNS requests in real time.

Note: I never tried to setup an Authoritative name server, so I don't know if there is any particular thing (technical or bureaucratic) to do.

Note 2: DNS modifications take time to propagate, so I suppose that also an Authoritative name server change will take some time to propagate world-wide.


How to set up full disk file encryption?

What you are looking for is "Endpoint DLP". All files are encrypted on the device individually.

Note that it can be very expensive, and there will be unexpected consequences depending on your environment. In many companies, such a control is too much. It is a better control when the company is already highly regulated, like a bank or a government office.

Imagine someone making a shopping list in Word on their lunch break. They can't send that file home or email it to anyone because the DLP system protected it. This can create a lot of friction with your employees.

It's a great solution, but it can be "too good" for many contexts.


There is only one way to make a site as secure as possible: take it completely offline. Everything else is a compromise: what browsers and clients do you want to allow to your site.

Even GitHub is still not as secure as possible. They allow TLS 1.0 and TLS 1.1 while there is a newer TLS 1.2. Disabling TLS 1.0 and TLS 1.1 would however deny users with Internet Explorer 7/8/9 on Vista which they are not (yet) willing to do.

To answer your question: yes, those other sites are not as secure as possible. But neither is GitHub.


Keeping a password safe in program config

If the password is going to be used and stored somehow on an untrusted client, then there is no real way to secure it. It would be in memory at point of use, and could also possibly be sniffed by a MITM impersonating the server.

A better solution would be to have a remote Web API with read access to the database table containing the value that needs to be monitored.

The Windows service then queries the Web API. If the data is sensitive, it is prudent to secure this service with some type of authentication and to protect it in transit using TLS. However, the main point is that if a client discovers the API credentials, the worst they could do would be to query the value being returned which is what the Windows service does anyway. That is, they won't have the access to read other tables, or to write to the database server. The API will only expose the one function, and the API itself would only have the minimal permissions necessary.


Trouble understanding SAQ A question 12.8.5

The entity would be the entity being assessed. The third parties would be the Payment Service Provider handling the transactions on behalf of the entity being assessed. There should be an understanding by the entity being assessed what are the compliance responsibilities being taken on by the Service Provider. This knowledge will allow the entity perform due diligence and monitor the Service Provider is satisfying its compliance requirements.


MD5 Algorithm: A basic explanation of the process

The simplest way to understand MD5 is to implement it from the specification, which is rather simple.

In very crude words:

The data to hash is a sequence of bits. Let's keep things simple, and let's assume that it is a sequence of bytes. A few extra bytes (the "padding") are appended to that sequence, so that the number of extra bytes is between 9 and 72 (inclusive) and the total length after padding is a multiple of 64. The specification explains the contents of the padding; basically a lot of zeros, and an encoding of the input data length.
The padded data is split into blocks of 64 bytes. The blocks will be processed one by one. Processing of each block (64 bytes) takes as input a 128-bit value (16 bytes) which is the output of the processing of the previous block, and outputs a new 128-bit value.
Since the first block has no previous block, a conventional fixed value is used to start the process. The MD5 specification details that value.
The complete MD5 output is the 128-bit value you get after processing the last block.

The processing of a single block splits both the 128-bit value obtained from the previous block, and the new block to process, into 32-bit words (4 words for the previous value, 16 words for the block). All computations are done with these 32-bit words. The overall structure has been described as akin to an encryption algorithm lying on its side: the 64-byte block is used as a kind of key to encrypt the 128-bit running state, in a generalized Feistel scheme. I am aware that such an assertion does not really explain things -- to really get what is going on in the algorithm, use your favourite programming language and try to implement it.

(Any language should be fine for such a task, since it is merely about learning, but some are less fine than others. For instance, Javascript's numbers are really floating point values, which is cumbersome for implementing MD5. Java and C# are good for such tasks, notably because they have integer types with a guaranteed 32-bit length, exactly what you need for MD5.)

You might also want to read this answer, which tries to explain why hash functions are "one-way", and takes MD5 as an example, so it includes a description of MD5.


Mac OS X terminal prompt displaying foreign hostname (or: What is Stacey's iPhone doing in my Terminal?)

At some point, your network assigned StaceysiPhone6s an IP address. Then, your laptop got that IP address. Your Mac then looked up the DHCP logs to find out who 'owned' that IP and found "StaceysiPhone6s". So, it used that info to set the local hostname value.

Example: https://apple.stackexchange.com/questions/30552/os-x-computer-name-not-matching-what-shows-on-terminal


Can malicious program open a file from mounted container?

If the volume is mounted, any process that has the rights to read the mounted filesystem will be able to open files in it exactly as if it were unencrypted. As soon as it is mounted, it is not encrypted at all from the perspective of the computer. This encryption can only provide data-at-rest security. That is, if the computer is ever stolen and someone gets their hands on the encrypted volume, they will not be able to decrypt it without knowing the original password you used.

  Should I worry about data in memory when working with files?

The issue is not that the files are present in memory so much as the fact that the data is not being protected when the volume is mounted. The system will happily decrypt what you ask! When you try to access a file, whether it's present on a partition that is encrypted or not, the requesting program will tell the operating system kernel (the core of the operating system) what file it wants to access. The kernel will then perform all the steps necessary to read the file, including transparently decrypting it and handing the decrypted data to the requesting application.


Received email at work from someone using a member's name

This is classic spam/phishing. The person being impersonated likely had their contacts scraped and the attacker is sending emails to each of the contacts.

No need to report to FCC. Inform the person being impersonated to change their email passwords (and possibly any other passwords) and to possibly email their contacts to let them know of the impersonation.


Do I need an ECDSA SSL certificate to use Diffie–Hellman key exchange method?

No. tls_ecdhe_rsa_with_aes_128_gcm_sha256 would use an RSA certificate and tls_ecdhe_ecdsa_with_aes_128_gcm_sha256 would use an ECDSA certificate.

Read again about how TLS works, what Diffie Hellman key exchange does, what digital signatures do, etc.


Asynchronous vs. Synchronous authentication process

Handling the requests synchronously on an event based server leaves you open to easy DOS, and certainly has a very negative impact on performance. Regardless of what type of server you use, a robust authentication system should provide some protection against brute force scanning.

The most common practice I've seen for protecting against brute force scanning is to disable an account after a certain number of failed logins - which, IMHO, is a DOS itself. A more practical approach is that implemented by fail2ban - after a certain number of failed attempts from a particular remote address, that address gets a temporary ban at the firewall.

The solution I've used in the past is to implement short queues for mutexes on the username and source IP address - the authentication is not tested until a request has both mutexes. If either queue is full then the request is failed immediately. This still provides some scope for DOS, but its scope should be far better contained.

All of these can be handled asynchronously.


How secure is my scripting code using windows encryption?

I’d comment if I had the points, but in my opinion that’s pretty secure, you can also make a basic key logger in that computer (or install one) that records incorrect password attempts in a file and sends the file has an email to you when it gets internet or you can just get the file if you go there, just to see if someone tried to enter or successfully entered to computer, you can also close all ports in hat computer that you won’t use, something like that.


Of course, you will always need an anti malware program even if you do not download files by yourself. Why ? Because a simple visit to the most innocent website you know, may trigger an attack and install you malware (more likely spyware) that can lead even to a total control of your machine.

I advice you to read about drive-by download attacks that can exploit the vulnerabilities of your browsers and or their plugins and install without your consent or knowledge more or less dangerous malware.

  When is an antivirus program needed/useful?

As I said, always. Unless if your computer is totally disconnected from internet and you never use any external media (USB sticks, external HDD, CDs ...) to read  data (in which case, your computer is useless)


Company name is used in Dropbox invoice scam

In practical terms:

try contacting your local CERT/CSIRT/CIRT (https://www.cert.org/incident-management/national-csirts/national-csirts.cfm) and make them aware of the issue
make sure you have some information available for potential victims, that explains you are aware of the issue, and are trying to do something. Consider making this information visible in places like Facebook/Twitter/wherever else you think people might be going to find out what is happening to them
try contacting your local police and reporting a violation of your commercial trademarks (or whatever analogue for that might make sense)
try contacting Dropbox, and see if they can do anything about the link, and whether they might also be prepared to link to your public info about the issue (total shot in the dark, but you never know).
if you think there is a chance it could help, consider contacting the relevant Network Information Centers (france: https://www.afnic.fr/, germany: http://www.denic.de/en/) and asking for their help. It doesn't sound like you are in the best position for that, but if the mails were trying to spoof/mimic your domain in some way, you might have some traction.

I suspect putting up a statement would be your first priority, as would be contacting Dropbox.

While I suspect (based partially on previous, somewhat similar experiences) you will have some difficulty with getting the police to take up your issue, I think that if you try and avoid pointing too much to the ransomware aspect, and focus on the commercial harm being done, you might at least be able to get a complaint recorded (this might be useful, or necessary, for the CERT to help).

The email itself is purporting to be an invoice from your company, so I do think you have pretty good grounds (I am not a lawyer, and even less so in Scandinavia) for reporting this as a commercial crime. This will probably not really help that much in practice, but is due diligence, and having a police complaint may be useful when dealing with other entities.

I think I would try and contact the local CERT first, if only because they might be able to help point you in the right direction with regards to recording a complaint with the police.

Do keep in mind, too, this sort of thing is far from uncommon, and all kinds of companies are regularly 'targeted' in this way - the ISC (https://isc.sans.edu) has some variation of this scam, often involving a big name multi-national, reported on most weeks.


There are several ways to DoS an individual IP address, and to answer you're question you can still use an HTTP DoS attack if they have an HTTP port that's open, so ultimately the best type of DoS attack you would execute on an individual IP address directly relates to the results of a port scan or other methods of reconnaissance and information gathering you would have to complete on that sole IP.


Your question contains a category error.

BSD sockets aren't a thing. They are an API to the kernel, comprised of a set of system calls. In theory, the code in the kernel, like all other code in the kernel, could have a security bug. However, the statement about 1983 does not reflect actual history. The only thing that dates from 1983 is the specification. The kernel code has been continuously maintained and frequently reimplemented over the history of the Linux kernel.

In any case, you have no choice. Sockets are the API to the internet on Linux. If you want a userland program to have a connection to the internet, you will be programming to the socket  API (unless you want to learn TLI, which has is just another interface to the very same kernel implementation).


Automated tools to test Struts OGNL security vulnerabilities

You can detect the use of known bad dependencies with OWASP Dependency-Check

I found this also looking for tools which attempt to exploit the known issues repetitively.  It's looking like I may have to modify existing active vulnerability scanners.


Are users meant to hash their passwords?

Users should not hash their passwords before sending it to a website. If the user hashes and sends the hashes credentials, the hash is acting exactly like a password and actually defeating the purpose of hashing. If an attacker steals your password hashes, they can just send those to your server to login.
You might want to read about Pass the hash attacks.
You must hash server side.


How dangerous are phishing links really?

Yes, there can be unique identifiers in links that will pair you with that "campaign" and you will be hit again with a more sophisticated attack, now that you are a known "clicker".
Yes, scripts on the webpage you click can steal your credentials, launch malware, encrypt files, etc. I did a video on how I investigated a sophisticated version of this and what exactly it did.


Do snowshoe and hailstorm spammers use auto-generated domain names?

Many of them almost certainly do.  I don't have a specific example to hand, but I have seen spam campaigns where the domains were made of several words, and often had the same words in different domains, leading me to believe that they were using a (relatively short) wordlist to generate the domains used for spamming.


Soft-fail vs Hard-fail SPF + Monitor vs Reject+Strict DMARC, could it be counterproductive?

... is there a situation where Hard-fail is counterproductive

Some mail servers actually reject mails on SPF Fail. Given that SPF has known trouble with mail forwarding services and some mailing list this might lead to loss of mails.

For use with DMARC it actually does not matter if SPF is Fail or Soft-Fail. All what matters is if SPF is Pass and this result is the same for both kinds of policies.

  The very same question I have for Monitor DMARC instead of Reject + Strict.

DMARC depends on SPF and/or DKIM, i.e. at least one of these must be fine and must have the domain aligned with the From field of the mail header. If you don't have a DKIM policy it thus all hangs on SPF which as I said has its inherent problems. While DKIM is more robust in this regard it can fail too, for example if the mails gets transformed during transport from 8bit to some ASCII encoding (base64, quoted-printable) due to missing support for 8BITMIME in one of the MTA on the way.

Therefore, the recommend setting is to actually start with none, monitor for a while if problems occur and if no problems occur move to reject or quarantine.


Resource authorization on multiple services

The more common pattern will be to use two separate authentications mechanisms:

auth for public-facing API (client to 1st microservice)
auth for internal API between 1st and 2nd microservices.

This way you can protect internal BE service from the external calls. The visibility of the internal API credentials should be a lot more restricted compared to external API credentials.

However, if your 2nd microservice in some scenarios is public-facing too, then double-check is unavoidable and what you are doing makes sense.


OAuth 2.0 client side redirect instead of HTTP redirect

Your question is very confusing as it's not clear who you really are or think you are... So, let's revisit the OAuth2 protocol.

The roles

  OAuth defines four roles:

  resource owner :
    An entity capable of granting access to a protected resource.
    When the resource owner is a person, it is referred to as an
    end-user.
  resource server :
    The server hosting the protected resources, capable of accepting
    and responding to protected resource requests using access tokens.
  client :
    An application making protected resource requests on behalf of the
    resource owner and with its authorization.  The term "client" does
    not imply any particular implementation characteristics (e.g.,
    whether the application executes on a server, a desktop, or other
    devices).
  authorization server :
    The server issuing access tokens to the client after successfully
    authenticating the resource owner and obtaining authorization.

If we take stackoverflow as an example, the roles would be

resource owner : Kinda you but more your browser (strangely)
client : stackoverflow
resource server : facebook
authorization server : facebook

Who are you?

You start by saying that you are the resource server and then you say the resource server is using node and angular.

  I'm implementing an OAuth 2.0 resource server using the Authorization
  Code flow (i.e. users will authorise client apps to connect to our
  server). The resource server runs Node on the server and Angular on
  the client and all client-server communication is over AJAX.

It doesn't make sense. The resource server is basically a webservice that is called by other applications, the clients, in order to retrieve information. Why would you use angularjs which is built to create a web application in a browser when the things that will access it are other applications that have no concept of a browser at all.

Who are you really?

Random guess would be that you are the authorization server, or more specifically, in regard to your question, the authorization server mentionned in the section 1.3.1 Authorization Code.

  The authorization code is obtained by using an authorization server as
  an intermediary between the client and resource owner.  Instead of
  requesting authorization directly from the resource owner, the client
  directs the resource owner to an authorization server (via its
  user-agent as defined in [RFC2616]), which in turn directs the
  resource owner back to the client with the authorization code.

Now back to your question...

Yes you can do it without any problem. More specifically, your authorization server can return the redirect command to the browser which will then redirect to the right page using javascript. It doesn't change anything in the flow so there shouldn't be any issue.

Where is the confusion then?

It's simply that AJAX doesn't work instead of the redirect but here it's not what you are doing. The flow goes like this :

client redirects browser to authorization server
authorization server redirects browser to client

A common non-working idea is that you could replace those redirect an AJAX request from the client javascript to the authorization server and get your authorization grant. It doesn't work because of the same origin policy and the users wouldn't have a chance to confirm the authorization grant. But it's not your case here so let's forget about that.

Conclusion

The javascript in a page is really just an extension of the server (when using https). The only difference is that it's a public part instead of a private one like the server. It's a public part because the user can see all the code and all the data.  You can do nearly all your logic in the javascript code, which is what you are doing with angularjs.

The only parts that should never be in it are the things that the user should never know. For example, the client secret which is why the implicit (1.3.2) authorization grant flow was created. In your case, you don't process any information that the user should never know hence there is no problem.

Reference : https://tools.ietf.org/html/rfc6749


ssh login failure detection at packet level

Before the password is sent, an encryption layer is added to the connection.

Also the encryption fingerprint is compared to the last time you signed in successfully. If there is an MITM inserting its own encryption layer then you will be alerted of the changed fingerprint. (assuming you have not already accepted the incorrect fingerprint by accident)

While the password, and the response from the server cannot be seen directly, it is likely that you can tell by the packet size and timing, and how long until the connection was closed, whether the login attempt was successful.

For example, this would be a single chunk of data with a predictable size.

Invalid username/password, please try again.

On the other hand, a successful login is several lines

Welcome! It's a great day at XYZ server!
Your last login was yesterday at

And depending on your server, there may be a delay between lines, which is sent in separate TCP packets as it comes in.

You have new mail.

you@xyz:~$

So yes, you can tell by monitoring packet size/count/timing whether the sign-in was successful. You cannot tell what password was attempted or exactly wad data was transferred.


How can i set an unbreakable password on py PC?

Remember, depending on your jurisdiction, your friends may be breaking the law.

There are a couple of really neat techniques to create near-unguessable passwords.

The first is online tools: just Google "strong password generator". For your needs, 8 characters should suffice. They should be generated randomly. If you can remember a phone number (typically 11 characters in the UK) you can remember 8.

The second is to pick four words at random, and then a capitalisation strategy of your choice. resilientHORSEBATTERYstaple would do.

A third technique is to use an equation. FIVEtimes5=25 or 5*five=TWENTYFIVE! would keep you safe.

However, a Windows password alone won't keep you safe if your friends are able to boot using a Live CD. This may be a bit advanced for you, but consider using an Encrypted Windows install next time you install Windows, or putting a password on your Bios. The Bios password is hard to do, and if you mess up you can break a lot of things, so just go with the above strategies as a first attempt.

Hope that helps!


Does posting the technique I used to encrypt my Linux system make the encryption inherently less secure?

Yes, it does make your system less secure, since it exposes internals to the world, and the next time an exploit is detected for a service you use, you can be an early target.

That being said, it may still be a good idea. Sunlight is the best disinfectant and by Kerkchoff's principle, secrecy of your implementation should not be a precondition for security. Since it is your first implementation, and you haven't revealed how to trivially find your system, a public review can only help.

This related post concludes that security through obscurity isn't bad, as long as you are not relying only on it.
Only counting on obscurity is bad. You want your system to be secure with the attacker knowing it's complete workings apart from specifically controllable secret information So I still suggest modifying everything in a few days/weeks (adding some obscurity)


How much of a certificate is actually covered by the CA's signature?

Actually you do not modify the certificate itself.

As explained here, the pfx file is container containing the certificate plus several other objects, including the certificate.

What you do in the given procedure is get the certificate out of this container, then put it in another container associated to different objects.

The certificate itself remains the same.


HTTP Verb tempering using MITM attack possibilities and prevention in rest api

If you fear a man in the middle attack you should protect against it by using HTTPS instead of HTTP. HTTPS is exactly designed to protect the data transfer against modifications by a man in the middle.

Using some kind of simple confirmation message instead will not help since a man in the middle attacker can also reply to this message or change the response presented to the client. While one might probably think of a more complex system of signed messages to deal with this properly, implementing this by yourself is much harder to get it right than just enabling HTTPS. Therefore using HTTPS should be the preferred way to protect against MITM.


Does an SSL Certificate (https) guarantee security without every page being SSL secured?

"Secured" is an overloaded non specific term.

SSL encrypts the connection between the server and client at the point in time that a connection is open.  That means the data is encrypted while in transit between the client and server.  It also provides cryptographic assurances that the certificate used to encrypt the connection was issued by a trusted certificate authority to an entity that has administrative control over the domain name in the address bar.

What happens after that is outside of the scope of SSL.  So no, once you're done submitting your secure information via a form, there is no reason to believe that it would be secured from the admin.

Something else to consider:

Just because a form is on a page that is using SSL, doesn't mean the form submission itself is secured with SSL.  The html form tag has an action attribute which points to a url on the server. The value on the action attribute can be setup in a 1 of 3 ways.

Use SSL if the containing page is using ssl.  Don't use ssl if the containing page is not using ssl.  An action attribute of this type would take the form of action="/formprocessor"
Always use ssl regardless of the containing page this would look like action="https://example.com/formprocessor"
Never use ssl, regardless of the contaning page.  This would look like action=http://example.com/formprocessor"


Why aren't telnet bots finishing the three-way handshake?

They are performing port scans, not trying to establish a connection.
This specific scanning technique is called a SYN scan. The idea is that you don't have to complete the entire TCP handshake to find out if a port is open. A SYN scan is often preferred to establishing a full connection because it's faster and less noticeable. From the nmap guide:

SYN scan is the default and most popular scan option for good reasons. It can be performed quickly, scanning thousands of ports per second on a fast network not hampered by restrictive firewalls. It is also relatively unobtrusive and stealthy since it never completes TCP connections. [...]
This technique is often referred to as half-open scanning, because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and then wait for a response. A SYN/ACK indicates the port is listening (open), while a RST (reset) is indicative of a non-listener. If no response is received after several retransmissions, the port is marked as filtered.

You can try to reproduce this behavior by attempting a SYN scan yourself using nmap and checking the Wireshark results:
nmap -sS yourhost

The bots can't possibly tell that it's not a real telnet service before they even finish connecting?

Correct, the disadvantage of this technique is that they can't really fingerprint the service. All they know is that the server has accepted a connection at that port.


I entered my password manager password in the browser URL field

It depends on the possible consequences. Estimate your risks.

1) For instance, if your password manager keeps passwords for your online banking account and similar important passwords, then the consequences can be very expensive and it makes sense to change the password and to delete any backups with the old password.

2) But if you keep there passwords for accounts like your local pet shop or for your local bowling club, the consequences in the worst case can be acceptable. Then you don't need to warry.

3) If your browser is configured to use URL field for search, then take into account that all major search engines use HTTPS only. That's why nobody except search engine could see your password.

4) Estimate what it costs for somebody to gain access to access to the servers of your search engine (like Google, Bing or DDG), find there requests related to you, then find a particular request that contained password. Then the attacker would need a copy of your password manager database. Only then he can use his knowledge of the password. Now estimate if it makes sense for smb. to do such efforts to get your passwords. If your passwords really cost millions of USD, it definitely makes sense to change password, delete any old copies. If not, don't waste time searching for the backups or copies of your password manager database on all your devices.


X.509 states that certificates use DER encoding:

  For signature
     calculation, the data that is to be signed is encoded using the ASN.1
     distinguished encoding rules (DER)

Nominally, you could imagine that you encode the certificate data in XER, and that the DER encoding of the to-be-signed structure (TBSCertificate) is performed dynamically for purposes of computing or verifying the signature, but nobody does that because:

It would be very hard to do, because although DER is suposedly deterministic, there are an awful lot of details which can get wrong (do you use UTCTime or GeneralizedTime for the validity dates ? How do you handle milliseconds in the date representation ? For DN components, do you use PrintableString, BMPString, UTF8String ? Which kind of Unicode decomposition do you use for diacritics ? And so on). It would not be reliable.
XML encoding is awfully inefficient, both in space (it uses a lot of bytes, even when compared with Base64-encoded DER) and in CPU (that can be a tough issue with reduced platforms like smart cards).
Certificates are all about interoperability, and nobody supports XER-encoded certificates, so there is no added value in supporting them right now. There is no incentive either: what XML can bring (compared to DER) is automatic support of generic data transforms (XPath, XSLT... you name it), but that's the kind of thing that we do not want to do with certificates, because a certificate is signed and you cannot change a single bit of it without invalidating the signature.

If you want to play with signatures on XML data, lookup XML-DSig. It is noteworthy that when an XML-DSig object embeds a certificate (as an X509Certificate element), it uses Base64 encoding of the binary certificate (i.e., DER-encoded certificate)(see section 4.4.4).

Summary: there is no such thing as a "standard" XER-encoded certificate and I predict that it will take some time before such a thing appears (and I pray all the gods I know that it will not happen before I retire).


As per my understanding of your needs, use SSL/TLS with mutual authentication (ie. client cert):

It will guaranty both ends identity,
Protect the communication confidentiality and integrity,
It is a well known standard, largely available allowing quick implementation.


WAP2 only secures the wifi against outsiders. Once you are in the inside, e.g. using the service, your transmission medium is considered trusted, and it is up to the other layers to use other means of security and/or encryption. Or put otherwise, the encryption done at WPA2 only is effective for who is kept outside the network.

Regular spoofing attacks techniques do work over wifi too albeit some professional equipments have mitigations measures.

Wifi gives you a emulation of a cable network connection once you are authenticated. ARP spoofing is done exploiting the way ethernet/layer 2 works. It does not matter which protocol authentication you are using, what it matters is that you are in an emulated ethernet connection for ARP spoofing to work. In an enterprise setting the complication is that broadcasts/ARP spoofing mitigation measures can exist as the equipment has more functionalities, but that got nothing to do with the authentication protocol.

Please also do keep in mind that while wifi is a shared medium, supplementary configurations can be done, like doing 802.1X and having VLANs inside wifi, and so effectively you will only be able to listen/spoof in the VLAN your login is authorised to access.

Far more serious than spoofing, is however if the wifi providers are compromised or bad actors. It is a child´s play to divert your requests via a untrustworthy DNS, and also routinely in wifi/captive web portals DNS requests for the outside are captured and divert to the internal DNSes.

Please see my other post in this thread for related considerations about hijacking browser connections.

Is HTTPS able to prevent ARP poison attack in LAN?

To put it simply, the above considerations are the reason why when you are in public wifis, it is advisable to use VPN technologies to protect yourself.


How to address XSS security issues in FCKeditor / CKeditor?

Usually there's not much you can do about vulns in 3rd party components.
Among your options:

Start by upgrading to the latest version. If that fixes it, you're done.
Contact the vendor responsibly, and get a fix from them.
If it's open source, try to patch it yourself - or find someone who did. Just make sure you do it right, and fixing XSS can be complicated and/or confusing.
If none of the above options are possible, consider removing this component from your system. It's always a risk, when taking some other component blindly, if you're not able to get it fixed...
In fact, make it a policy to do a security review on any 3rd party code before integrating it into your system.
If you absolutely MUST continue to use a vulnerable component - reconsider :). But really, if its a done deal, consider protecting it with a WAF (web application firewall). Doesn't solve the problem, but it can help prevent exploitation...


Accepting an untrusted security certificate?

X.509 security certificates are mainly about the authentication of the site providing it, i.e. you know the site is really the site it claims to be. This is why e.g. banks use certificates at a high trust level (which means they are signed by more certification authorities, signed by more established cas rather than unknown ones, etc.).
Even without providing any data, with untrusted certificates, you have the risk of becoming a victim of a man-in-the-middle attack or phishing, where someone tries to either modify or spoof the site you're visting. This way, you might get false information, which can do in certain cases as much harm as stealing your credentials.


How to call webservice securely in Android

It's simple. Never trust the client.

Never rely your business on storing any secrets in the client that the user are not supposed to know.

It doesn't matter whether this is Android, desktop, or whatever. Unless you're prepared to secure your device like an ATM (bolted onto a wall in a weighted safe, and cameras all around), the client is not to trusted. And even if you are on an ATM, still don't trust the device.

  How to secure such that any attacker can't get anyhow my WEB API KEY which I defined in the strings.xml

You can't. You don't need to.

Authenticate per user and per device. Users shouldn't be sharing the same API key with anyone else, the API key should authenticate the user or the user's decision rather than the client.


How to validate report given by a white hat hacker

Trust is a prerequisite: Even before signing the contract allowing a third party to try to break into your server, there should be a minimum background check regarding who you employ for the job (where do he comes from, what company he is working for, how much experience he has, which certification does he and his company have, etc.),
Check your logs: After the attack, even-more if he claims he failed to find any security vulnerability (so he did not had a way to alter the logs), his thorough checking should have left clearly noticeable tracks in the logs.


The issue is not that the address is "small", but that you are trying to print null bytes (\x00) as a shell argument. This is not possible with bash, to my knowledge, as it uses null-terminated strings.
Depending on the program and exploit, if the memory you are overwriting already contains null bytes, you may not need to write them again. For example, you may be able to do a partial overwrite with just \x7d\x05.


One way you could do this is with Shamir's secret sharing. Your song data would be prefixed with a known-good value (e.g. "RIGHTKEY") then encrypted with a symmetric cipher such as AES-CTR-128, and the shared secret S would be the AES key converted into a 128-bit integer.

Using Shamir's you would generate your 20 points on the curve, each in the form [x, f(x)]. Assign each point to a question, adding the answer's correct value (mapping a,b,c,d to 1,2,3,4) to the f(x) part, such that you get points in the form [x, f(x)+q] where q is the correct answer index 1, 2, 3, or 4. If a student were to look at the page source code, they would only see a point [x, y] and would not know what the value of f(x) or q is.

Upon submission of the completed answer sheet, you go through each answer and subtract the given answer's index from the second part of the point. If the answer is correct then their value will have been subtracted back to the original value of f(x). If enough of their answers are correct, they will have enough points [x, f(x)] to decrypt the secret. As some of their answers may be wrong, you can't just use all of the points. Instead, you iterate through each possible combination of k answers and attempt to compute the shared secret, then use the resulting secret to decrypt the first 8 bytes of the encrypted song and see if the data is "RIGHTKEY". If so, you know you got the right key. If not, you move onto the next iteration and try again. For a value of k=16 with 20 questions, you only need to do 4845 attempts at most; for enough correct answers this will be much faster as you are likely to find a correct combination early on in the decryption process.

Against a naive bruteforce approach, the system has a security bound of 4k for a threshold of k correct answers. The primary weakness is that if a test-taker is absolutely sure of some answers but doesn't know others, they can use the ones they know are correct to reduce the brute-force space significantly. Ultimately, however, this is an inherent problem for any client-side validation approach using thresholds. The only way to avoid this is to have the exam validated on the server-side against a set of known answers.


Would designing a crawling bot to detect and inform vulnerable website owners be legal?[Heartbleed]

Assuming that you had the website owners express permission to test for the vulnerability - probably, depending on your location (UK/US/EU laws appropriate).

Having a crawler that scans for the vulnerability is (in my opinion) almost certainly breaking some law in whatever country. Not only this though, imagine it from the business/website owner's perspective - what's your real intention?

As a side note - You've got to be careful going down this route as, even though you're trying to do the right thing (presumably) and make a small amount of money (again, assuming) this can be interpreted in two different ways:

I know how to fix this issue, I'll let the client know and they can pay me a tiny fee for doing so (or free because I care about security).
I know how to fix this issue, I'll let the client know and force them to pay me a ransom or else I'll tell everyone about their flaw.

Almost everyone reading your email/letter or listening to your phone call is going to think they're being scammed. Further to this, if you inform a client that the vulnerability exists and that you've scanned their server/site and found it there - you've just sent them an email saying the following (in the eyes of the UK law, others might be different):

"Hi, I scanned your website without permission and discovered a flaw. I can bypass security/access confidential data. Please secure this."

What happens if within 3 minutes of sending that email, the server is compromised using the method your just described? Even if they know it's not you, they'll be ticked off that they've just lost data and assume it was you. Even if there's a lack of evidence it's still hassle you'd rather be without.

I'd suggest creating a website where people can test their own sites and servers by typing a hostname/IP Address into a box and agreeing to some t's and c's that make you non-liable.


Does a WAN to LAN Route Conversion Through a Router Adds Security?

In a WAN you do not have control over the traffic, but in a LAN you do, you can for example restrict physical access to the network, implement security policies...
But when you connect the two, you lose that control, because (again) you dont have control over the WAN part, and being the WAN a bigger network than the LAN the threat profile is much bigger.

The benefit as I see it, is that in a LAN you get to implement security measures like a firewall, or a honeypot, but I wouldn't say that just by connecting a LAN to a WAN you get any security benefit by itself, you need to work to actually get that security improvement.


Store provided external user data encrypted in the database

I'm not even sure how your Idea #2 is supposed to work - you don't ever encrypt anything with private keys, and I'm not sure how your retrieval flow would decrypt the data if you did since you apparently would have used a different key depending on how the data was sourced - plus RSA makes an absolutely lousy bulk data cipher and there's literally no reason to ever attempt to use it as one.

Idea #1 is valid, though. It does have some "gotchas" but the basics of it are solid. Provide a public key (after authentication), data is encrypted (and gets a MAC / signature) using a random DEK and then the DEK is encrypted using the public key and stored along with the encrypted data. Retrieval requires using a password-derived key (PDK) to unwrap the private key, which then unwraps the DEK for that item and the DEK is used to decrypt the data. Elegant in theory, although there's some stuff you want to look out for (like, what if a user changes their password? Then the PDK changes, so you need to unwrap the private key with the old PDK and re-wrap it with the new one).

One thing that's not entirely clear from your description of the service is where the encryption and decryption is happening. For this sort of end-to-end, zero-trust encryption to work, you need the client to be the only one who can unwrap the DEKs, which means the server can never even receive the data necessary to derive the PDK. It also means the client must do 100% of the encrypting and decrypting, because the server neither ever sees the keys nor the data in plaintext.

In a system like that, you need a certain amount of complexity in your client; it's unavoidable. You can do this with a modern browser no problem - the modern JS crypto library is quite capable of all this, and there exist polyfills (of varying quality) for older browsers if you don't mind the performance cost of implementing crypto primitives in JS - but you can't do it in some external service that wants to push data to your system and the only parameters it accepts are "what credentials do I use and what URL do I send the POST request to?".

You'd need some sort of middleware that can take the data from the external service, authenticate to your service, and perform the crypto before pushing the encrypted data to your server. This is entirely possible but definitely increases complexity. It gets even worse if you need to be able to retrieve the data through such middleware; inputting data can be done without needing a PDK (since the PDK is only needed for the private key) so it doesn't need the real password and can instead use an API key or similar (sufficient to retrieve the user's public key, but no ability to unwrap the private key needed for the DEK). However, any client that wants to retrieve data needs to be able to unwrap the DEKs, which means it needs to unwrap the private key, which means it either needs to know the user's actual password (although it still never sends it to the server, otherwise the server can also unwrap the private key) or the private key needs to be wrapped (encrypted) using multiple client-specific keys (one is the usual PDK, another is based on some secret stored in the middleware or whatever) or else the client/middleware needs to store the private key long-term.


Why http cookies are automatically sent to the server upon a http requests and CSRF

According to Wikipedia, the concept of cookies comes from Lou Montulli in June 1994. The HTTP protocol was still very young.

Since HTTP lacks some fundamental security features, such as encryption, I guess security wasn't their priority. I also doubt that any of the people working at that time could have anticipated that HTTP would be so wildly used nowadays, even by evil actors.

It's way easier to look back at all the vulnerabilities / specs flaws we found in the latest 20 years, that to anticipate them all in the first place.

As you've said, the SameSite cookie attribute is on the way to fix that flaw. Until its support by browsers, developers should use standard CSRF mitigations techniques.


How do I get the "vulnerabilities history" of a Node.js package?

If you are searching for vulnerabilites in packages and software I would suggest to look in databases like https://cve.mitre.org/. There are all common vulnerabilities and exposures listed you are talking about.
Just type your software into the search field and hit submit (like wordpress):

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress

BUT: Take care. These listed vulnerabilities are just the known ones. If you look a version up and cannot find anything it doesn't mean that there are no problems with it.


Is it safe for a client server to log into a non-trusted server with SSH?

It should be as safe as HTTPS, meaning that a malicious server would need to be able to exploit some vulnerability in the client in order to abuse the connection -- which is true for both HTTPS and SSH protocols.

However, you should make sure that you don't forward your ssh-agent to servers you don't trust. A good way to ensure that is to set the following in your .ssh/config:

ClearAllForwardings yes


I have seen this behaviour in nmap before, and from my experience it doesn’t have anything to do with nmap itself, but the devices that are being scanned.

I think the actual problem here is the device’s firewall blocking the scan. This can be because of different rates, different ports and other custom options on firewalls (you might not even know exist). Some firewalls open and close ports rapidly. My android phone was popping on and off the network just like this.

Before trying anything else, you should check the firewall on the devices. You can also scan more using -Pn or try using masscan to see if the problem persists.

This may not be qualified as an answer, but atleast it’s something to be aware of.


If you want to do something, you can report the SPAM.

Depending on your country of residence, you may have different number where you can forward the spam SMS (7726 in the US, 33700 in France, 1909 in India, as mentioned in the linked Wikipedia page). This among other thing is meant to help to detect such messages (still according Wikipedia). You may also have web page to report them (like this one handled by the Federal Communication Comission).

In other words, search for "how to report SMS spam" and you should be good.


What is the benefit of combining a form with php processing script in a single page using isset

There are no benefits or drawbacks security-wise.

Technically it's always two calls to the server, one to load the form and one to process it, no matter how many files you have. So it's just the way to organize your files, nothing more.

No, isset() cannot cause problems with null values, as a regular HTML form cannot send values of any type other than string - so there would be not a single null value to deal with.

What is very important to understand: anything could be faked.

the form could be read or could be not
The handler could be called by a browser from the form page, or could be called by a bot with the form fields completely forged. There is no way to tell one call from another.
the form could be read, but the data could be tampered with, fields removed or renamed or edited
some fiend types (notably checkboxes) are not sent from the form if not selected

So you should treat your handler script as a self-sufficient application that doesn't trust anything sent from the client side. And, among other things, you should always check whether the form has been set, no matter if it's a single script or two separate ones.

Besides, there is no use for isset() if you have the form and the processing code on a single page as opposed to having two pages. isset() is just irrelevant to that. Once you need it, you need it for both implementations.


Will Let's Encrypt allow a custom workflow?

Yes, you can use LetsEncrypt with complex configurations that the command-line tool cannot modify.  There are two ways to do so:

The hard way: Write your own client that follows the ACME specification and does whatever it is that you want to do with the certificates.
The easy way: Use the LetsEncrypt client in "Standalone Authenticator" mode.  In this mode, the verification will be done using a standalone webserver that runs inside the LetsEncrypt tool and the certificate will be saved in a folder for you to use as you see fit.

The Quick Start has an example of using the command-line tool (via Docker) in this standalone mode, which saves the certificate into /etc/letsencrypt/certs.

sudo docker run -it --rm -p 443:443 --name letsencrypt \
              -v "/etc/letsencrypt:/etc/letsencrypt" \
              -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
              quay.io/letsencrypt/lets-encrypt-preview:latest

I extracted the command that is run from that Docker image so that you can run it outside of Docker on a machine that has the client installed directly:

letsencrypt --text

Yes, that should be all it takes! (In fact, the --text part probably isn't required either.)


Can someone tell me whether this is Cross-site scripting attack or normal log entry?

I did URL decode on the string you provided.This seems a normal log entry
.Below are some of the things I could tell from the log entry:

The IP address who tried to browse to this page is 10.160.241.146 on
port 443 " to be honest I don't remember if this is one or the one at the start of the log entry, I need to look it up"
The browser submitted the following user agent header
mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729;+.NET4.0C**
The other part is just the URL with parameters being passed.

if that page is not usually visited by your users that might indicate an automated tool trying to specifically look for AJAX Control Toolkit ToolkitScriptManager.cs TSM_HiddenField Field XXS. You should inspect your logs looking for more evidence. You should look at the logs for the offending IP.


How can I trust a server's public host key when I first login remotely?

In order to ensure 1st connection to ssh server, you have to verify his public host key.

For this, each new connection to an unknown host will prompt fingerprint and visual ascii graphic corresponding to host's public keys.

To make this verification, there are many different ways

Ask personely server's sysadmin for the fingerprint of the public host key (by phone, fax, meet or any trusted way)
Ask a confident friend who already done previous job
Go away but don't trust your connection until you could see physical proof you are on correct host (making a reverse connection from host, instant publication, etc).

From server side, when you install the SSH server, installation procedure implie host keys generation. At this point, all server keys are show with fingerprint and small ascii graphic you could check and compare.

This could be shown by the use of

ssh-keygen -lvf keyfile

Sample

mkdir /tmp/testsshkey && cd $_
ssh-keygen -b 1024 -f /tmp/testsshkey/key01
mv key01.pub other.pub
diff <(ssh-keygen -lvf key01) <(ssh-keygen -lvf other.pub )
1c1
< 1024 SHA256:7WuWSSOigkJ0UOPABdsrdkO3zYizPd3EfVpxb4XgeDk no comment (RSA)
---
> 1024 SHA256:7WuWSSOigkJ0UOPABdsrdkO3zYizPd3EfVpxb4XgeDk user@sondbox (RSA)

The only difference are in comments.


Tablet / phone app security in unsecured networks

Well, this is obviously a trust issue. You believe (rightfully) that your devices establish connections you didn't ask for. You suspect (again, rightfully) that those connections aren't always encrypted and that your information may be eavesdropped on when using insecure networks.

Even if there was a way to ask the device what data is sent out, would you believe it?

Your best bet is, like you said, to set up your own wireless network and dump all the traffic. In my opinion, there are so many parts of the device that can communicate with the outside world (the OS, the installed applications, the baseband, ...) that you're really better off trying to enumerate the outbound traffic from a "black box" perspective.


Semi-complex passwords would be much less secure than complex passwords (but more secure than simple passwords).  Ideally, a password should be long, have numbers, special characters, capital letters, and lowercase letters.  Long passwords are especially to be desired because each additional letter makes the password 26 times harder to guess if only lower case characters are used.  If uppercase characters are also required, this makes it 52 times harder to guess per additional character.  If numbers are added, each character makes it 62 times harder to guess.  Special characters increases this further.

Keep in mind that a 5 character password can be easily brute forced with modern technology and is not very secure, so you will want much longer passwords.  As technology advances, even longer passwords (or other methods of security) will be required.  As for the effects on mobile phones and operating systems, it depends on their implementation if adding these requirements would cause a problem, but it shouldn't.   I have encountered websites that don't like special characters in passwords, for example, but this could be fixed by the site's implementation.

Another thing to consider is that long passwords on a phone are harder to enter, as pointed out by Bill Weiss in the comments.  For this reason, it might be good to consider alternate authentication technologies (e.g. pin / biometric / tokens) as well.  This has prompted me to ask the following question here, which may come up with better ways to authenticate than passwords: What is a good way to authenticate a user to a smart phone?

The following analysis from xkcd.com shows the value of longer vs. more complex passwords (although the example they post might be more easily cracked with a dictionary attack).


Using VPN and hidding this fact from ISP.

I recently ran into a similar situation.  An internet connection I was legally making use of was using deep packet inspection to prevent the use of SSH Tunnels or VPN.

To get around this I setup an instance of ShadowSocks with SSH Tunneling through it (example).

Shadowsocks - obfuscates the content of the connection making it much harder for deep packet inspection to identify the type of traffic (though not impossible).

SSH - provides much better security than Shadowsocks as well as provides a means for tunneling other types of traffic through it.


Securing REST API with HMAC and basic auth

It is not clear for me which kind of problem you are trying to solve and it might not even be clear to you. If you have a clear idea what you are trying to achieve with the authentication than you would not need to offer the client multiple authentication schemes but stick with the one which solves your problem.

If you fear a compromise of the authentication credentials because the connection might be sniffed simply use TLS. In this case basic authentication, session cookies or similar "clear text" authentications offers enough protection since the secret is protected during transfer.

If TLS is not possible you might use challenge response methods where you have a pre-shared secret key. This protects the authentication but does not protect against hijacking of the connection, i.e. a man in the middle could pass the authentication and then modify any actions done inside the authenticated connection. With proper use of TLS this would not be a problem but then you could also use simpler authentication methods.

There are other authentication methods (like mutual TLS authentication) but I recommend you first determine what needs to protected and what kind of misuse you want to be protected against. Once this is done you can select from the existing methods the one which matches your problem best.


How to secure REST API for parameter manipulation?

Your request, at least how you describe it, isn't authenticated. This means that anyone at any time can send such a request and trigger a transaction.

I assume that TLS is a given, as you are using HTTPS in your example URL. This is of course a must have.

You need to implement the following mechanisms to protect your API against this problem:

Authentication: You should authenticate the user sending the request. There are many different authentication protocols available and the right choice depends on your architecture. It can be something straight forward like basic authentication or something more complex like a token based OAuth implementation.
CSRF Preotection: Again, I don't know your application architecture, but in case you have a web-frontend that triggers the API calls, CSRF might become an issue. In this case you must also ensure that CSRF protection is in place to avoid missuse.
Replay Protection: After implementing 1. and 2., you have to evaluate, if there is still a risk of replay attacks. If that's the case, you have to implement a scheme that ensures that a duplicate gets detected (e.g. every request has a random id that gets tracked).


Is disabling auto-run enough to protect against malicious code from removable media automatically infecting a machine?

There are several known ways that a malicious USB device can compromise your computer:

Autorun.  The USB device can contain software that Windows will automatically run when you plug in the USB device, if you have autorun enabled.
Input device emulation.  As @TobyS says, the malicious USB dongle might physically look like a small flash storage device (a dongle), but it can still present itself to the computer as a keyboard or a mouse or somesuch.  Then the malicious USB device might start inserting malicious key strokes that subvert your computer.
Exploit a vulnerability. The USB device can contain data or files that exploit vulnerabilities in the code that runs on your computer.  As @Jeff mentions, this might include exploiting vulnerabilities in the code that displays file icons in your file manager or exploiting vulnerabilities in your anti-virus software when it scans the drive.  It might also include exploiting vulnerabilities in the OS filesystem code (I have seen bugs in that code before, which could be exploited by a malicious filesystem image) or a number of other variants.  While I don't currently know of any zero-day vulnerabilities with no known fix in the latest Windows OS, there is a lot of code that runs to handle data from a USB device, and you should assume there are probably more vulnerabilities lurking, waiting to be found.
Social engineering. The USB device can contain files that, when you double-click on them, launch malware.  The file names and icons might be arranged to look tempting, to entice users to click on them.  This has been exploited before, and is very challenging to prevent.

Bottom line: disabling autorun is a good start, and stops the easiest form of attack.  For a company that doesn't have especially high security needs, it's probably "good enough".  (It is good enough for me in my own personal computing.)  But don't think it's enough to be completely safe; autorun stops only the first of the attacks mentioned above, and other attacks remain possible, as sketched above.  Because of these risks, the military completely bans all USB drives.


VMSphere Documentation Centers recommends zero-ing out the entire contents of the file before deleting. While I understand you are running, VM Workstation 11 the same logic would apply. It is recommended that you boot the VMFS from CDROM/ISO that contains a program to wipe a hard disk (e.g. DBAN, etc.), wipe the entire contents then delete the .vmdk.

For further assurance, you could follow the directions of @Tim and @John. You could use a program like CsCleaner, sdelete from MS SysInternals, or other file deletion tools to delete the .vmdk. However,  if you will continue to use the physical hdd, it is important that you use full disk encryption until the time comes to decommission the physical drive, when you securely wipe & destroy it.


Thoughts on Tiny Encryption Algorithm (TEA, anyone)?

TEA is cryptographically broken. Its successors XTEA and XXTEA fare much better in that respect. Also, the performance of the *TEA algorithms is not very good.

The good point of TEA is the tiny code size -- this is a great asset in situations where code size is constrained, e.g. when you want to learn the code by heart, or when the code is part of often-downloaded software (e.g. a Javascript implementation). This does not apply to a PHP implementation, which stays server-side. So there is little point in using TEA or XTEA, and my advice would be to stick to a faster, more secure and more standard encryption algorithm (i.e. AES, also known as Rijndael).

(Also, encryption is only part of a data exchange protocol; you also need some kind of integrity protection, and there is the whole issue of key management. Usual recommendation is to rely on an existing protocol which already covers all the tricky details, first and foremost being SSL/TLS.)


If this is the case, doesn't this logic essentially adhere to the
  'security through obscurity' mentality that is generally frowned upon?

Security through obscurity is only frowned upon when used instead of a more fundamentally effective control. Typically it is best to apply multiple layers of security, and it is perfectly acceptable and beneficial to use obscurity as one of those layers.

For example it's fine to name the text file storing your encryption keys something obscure in the hope that if someone compromises your system they won't be able to find it, but don't put that text file in a publicly accessible place just because it's named something obscure.

Using your scenario, it's fine to derive security benefits from running a less common platform - but don't forgo other controls such as a firewall and general security concious behaviour just because you're running Ubuntu.

  What other security advantages are there to switch to Ubuntu, or
  another Linux distribution more generally?

There is nothing that makes Linux fundamentally more secure. Some controls may be implemented or applied differently, but there is nothing that makes Windows outright less secure. Plenty of people can and do run highly secure systems on Windows.

It's possible that on average fewer security issues occur on Linux, but if that's the case then it's probably due to a combination of secondary factors such as:

Linux users in general are likely to be more security concious, not click on popups, open dodgy attachments, etc.
Linux users are less likely to operate in a privileged environment (eg. by default not running as root vs. a lot of people who turn off UAC on Windows)
Arguably it's easier to update vulnerable software using a package manager on Linux

On the other hand, there's several factors which cause me to believe OS choice isn't that significant in terms of security overall:

It's not that common that OS vulnerabilities are primarily responsible for an intrusion. More often the malware gets in via a vulnerability in some other application or by user error, which then might exploit the OS once in.
Arguably Linux users are more valuable targets on average because they're more likely to have access to other systems, servers and production code.
Linux has the majority in the web server market, and there's plenty of both successful and unsuccessful attacks, malware, and vulnerabilities for Linux in this domain


Risk Control - Ignored risks and accepted risks

Despite the gigabytes written on risk management, I don't think there is a consistent, coherent terminology for risk management.  So the answer to your question is local; unless you define "ignore" differently from "accept" within your risk management program, there is no difference.

That said, I would suggest that if I were one of the decision makers, I would treat the two differently.  Even if I were to accept a risk, I would continue to monitor that risk, periodically re-assess that risk, and consider assigning risk triggers and risk metrics.  I'm accepting that risk today because of my evaluation of the risk likelihood and impact, the cost and efficacy of my potential responses, and my priorities.  Next month those factors may change.   In my mind "accepted" risks are still managed, but "ignored" risks are not.


Does SIEM has future

Yes.

  like is it going 100% automation

No.

  like an Analyst need to monitor and analyse?

Yes, but hopefully less than they do today.

  Or how the SIEM tools will be in future?

More automated analysis, but still reliant on humans to discriminate between false and true positives.


Application of Bayesian network for Web Application Security

Bayesian networks are a form of probabilistic model, whereby a set of conditions can be used to predict whether an assertion is true or false.

For example, let's suppose there are two conditions we are using to predict whether a disk is dying.

Disk writes are slow.
Traffic is abnormally high.

We might formulate the probabilities like this:

  Slow Writes | High Traffic | Disk failing?
--------------+--------------+-- T --|-- F ---
      F       |      F       | 0.05  | 0.95
      F       |      T       | 0.01  | 0.99
      T       |      F       | 0.90  | 0.10
      T       |      T       | 0.45  | 0.55

This can be interpreted as follows:

If writes are not slow, and traffic is not high, there is a 0.95 probability that the disk is not failing.
If writes are not slow, and traffic is not high, there is a 0.99 probability that the disk is not failing.
If writes are slow, and traffic is not high, there is a 0.90 probability that the disk is failing.
If writes are slow, and traffic is high, there is a 0.55 probability that the disk is not failing.

We can take this type of model and apply self-learning to it. We take a large set of data where the outcomes are known, and use this to build a probability model.

For example, in a network we might have tests such as:

>10Mbps TCP traffic coming from internet?
>10Mbps UDP traffic coming from internet?
>5 failed logins to RDP in last 10 minutes?
>5 failed logins to SSH in last 10 minutes?
Number of TCP connections to SQL server is >5?
Number of TCP connections to HTTP server is >500?
Firewall has logged >100 events in the last minute?
Time is currently within office (9-5) hours?
etc.

We run these tests over a set of known traffic on the network, and inform the model of times where a breach has or has not been attempted. It can then check which tests were most likely to correlate with a particular type of target event, and build a probability model like we did above.

When we detect further breaches, we tell the model "this was a breach", and it can attempt to improve its model. We can also tell it when it falsely alerted us to a breach.

These models can become extremely complex when dealing with large numbers of question and huge datasets, especially when the model contains test questions that are fed from sub-models, or other forms of analysis. As such, they can provide an excellent pattern-matching approach to intrusion detection.


Remote Worker Sharepoint Access Permissions

My general suspicion is that your desires are mutually exclusive.  Effectively, you are trying to give someone access to your data while also not giving them access to your data.

If the data is so sensitive that someone could use this opportunity to steal your data and potentially sink your business, then I think there is really only one option: do it yourself.  Or find someone you really trust.  I mean, here is a basic flaw in your system:

User opens up file marked "TOP SECRET CLASSIFIED DO NOT SHARE" in your virtual machine
User takes a screenshot from their computer
User shares your top secret data

That's just the first thought that I have off the top of my head.  I'm sure that if the person you put in charge of this really wants to steal your stuff, they will find a way.  You can't simultaneously give someone access to your data and not give them access to your data.

Do it yourself.
Find someone you trust.
Have someone local do it and watch them the whole time

I don't really think you have any other options.


I'm not so sure you are attacking this from the right direction.

Trusting a 3rd party means you are already at risk
Assembling a lot of data at one point is a huge risk
Connecting to a 3rd party means they might have logs of IP addresses (like your connection to get email and SMTP senders)

Very Paranoid

If you want to be truly paranoid, you would want encrypted and signed emails, an anonymous account somewhere, and a way to hide your IP address using a proxy (maybe TOR?).  You would also want your senders to carry out the same steps so you can't be tracked down via them.  As you get more paranoid, you might want a different email address for each sender, and still more yet.

(i don't have time to write more, but i think there might be some good compromises to make it usable and more private)


How integrity is compromised if forward secrecy is not enabled in TLS communication?

Generally, the integrity wouldn't be impacted. Usually it can't be, really, since the communication was presumably recorded some time ago. However, the symmetric key used for integrity (HMACs or AEAD modes) is exposed, and that could be a meaningful impact in some specific cases.

The attacker has a man-in-the-middle position on an ongoing TLS channel, and compromised the private key after the TLS handshake but recorded the handshake and encrypted traffic. In this case, the attacker can now modify or forge messages that the recipient (client or server) will think are genuine.
Attacker has recorded a TLS session and then (without the victim's knowledge) compromised the private key. The attacker can decrypt and modify the recording, and re-encrypt with patched integrity codes. This recording could then be offered to the victim (or any other party with access to either the private key or the ephemeral symmetric key), with the attacker claiming that it is genuine ("after all, if I changed anything the integrity codes wouldn't verify") in order to "prove" something was/wasn't sent. (As a side note: since the "legitimate" traffic thus "recorded" would effectively be authenticated by the certificate used in the key exchange, it would effectively prevent repudiation by the server, if the server owner were compelled to produce the key. This generally isn't a consideration of TLS, but could be relevant in some cases.)


Search on email domains using the Have I Been Pwned API?

You cannot do this. You can only get all breaches for an entire e-mail.
If you want to get all e-mails from eg. Gmail you can download some breaches and just grep it.


I'm sorry for the long answer, but I felt it's needed here. Plus, you're not the regular OP looking for a quickie. I've looked into this when we studied GSM in school. The are several methods to find out the SMSC from your phone; however, that's completely different from what you're looking for.

Let's start with how an SMS is sent (very basic description): The sender sends a message sending request to his serving support node. This request contains the message itself, the destination, and the SMSC (the sender's SMSC). The request is then forwarded to the service centre of the SMSC and stored there.

When the message needs to be delivered (usually, immediately after storage in the SMSC), the SMCS' gateway looks up the recipient's information to find the correct route to their MSC/SGSN. The message is sent there, and then forwarded to the actual recipient.

When the message reaches the actual recipient, the only trace-aiding information is the source of the message as it appears to the recipient (effectively, some sort of identifier/address leading to a gateway in the recipient’s network). The races will lead you to your provider, from there on you need to request information from them.

Remember when I said that what you're trying to find is not what you actually need? Well, that's because what you're trying to find is your SMSC which is configured in your SIM card from your provider. This SMSC is used when you are sending a message, but not when you're receiving a message. Even if you find this address/number (not really difficult), there's nothing you can do with it; it's the address/number of the SMSC of your provider.

Bottom line is: To trace a spoofed message, you need to see the logs of your provider's gateway which will lead you to the sender's SMS gateway which will lead you to the sender's SMSC which will lead you to the sender which, unfortunately, will not be the actual sender (your friend) but spoofing service. Then, and only then, you'll be able to be sure that this message was actually sent by a spoofing service.

If you're looking to dive deeper into this, please have a look at the SMS protocol specification 3GPP TS  23.040


How do I check that I have a direct SSL connection to a website?

To verify that you're talking to the remote server you want directly, two points are required:

You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.
There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.
MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.


Any way to know if a sniffed packet contains a downloaded file?


What is the right way of storing database connection strings from the security point of view?

Best option: Don't use a password for the database, but instead employ (Windows) Integrated Authentication if it's possible, and of course isolate the application's identity that is authorized for the database. That way you have the OS/Webserver/SCM manage your identity, in a very secured manner.

If it's not possible to go the way of Integrated Windows Authentication (IWA), you'll need to securely encrypt the connstring, preferably using something like DPAPI (so you dont have to manage the encryption key), and store the encrypted value in a protected Registry key with strong ACLs.
If you are on ASP.NET (from your comments, but not OP), there are built-in tools to do this automatically (aspnet_setreg, aspnet_regiis, etc depending on version...)


What browser are you using?
For example if you use firefox and set up DuckDuckGo as your main search engine it will use HTTPS by default.  Firefox DuckDuckGo Plugin
This are the instructions for firefox, chrome, opera & safari .

The great thing about DuckDuckGo, is that you customize it to your need (settings).  You can specify there under Privacy Settings to use HTTPS by default. At the end it tells you how to keep the changes (Load/Reset Settings).

You could follow the same instructions on this answer and would increase DuckDuckGo security, but IMO it would be a bit overparanoid.

Post is generally faster, and since DuckDuckGo isn't as popular as Google they want to leave a good first impresion (assumption), thus fast and effecient results is the priority. User can add HTTPS later on as their default search option.

Edit
HTTPS needs a initial handshake which can take some time, if most of the data is sent through the initial request, performance will not be that significant.

SSL may decrease performance, in a way; Search results can be large spaning pages (take in account duckduckgo provides scrolling rather than clicking on next page) this might burden the system to encrypt all of this.

Also take in account, not everyone need HTTPS, even though it is recommended to use HTTPS.


Encryption: Files that can't be encrypted/cryptolocker family doesn't encrypt?

No, any data can be encrypted. There are some types of data it doesn't make much sense to encrypt (e.g. data which is already encrypted), but there is nothing that inherently prevents you from doing it. Remember that most encryption algorithms don't work on files internally - they work on streams of bits. Since all files are made of streams of bits, they don't care what the actual content is, and will happily output a different stream of bits which we call the ciphertext or encrypted file.

As a result of this, technically there are no restrictions on what any ransomware could encrypt. It would be entirely feasible to have a ransomware application which used the Truecrypt source and performed full disk encryption, leaving a minimal boot area prompting for a decryption key once you've paid the ransom.

Any files which aren't encrypted by cryptolocker or other similar malware are down to specific choices by the designers. They may have decided that encrypting .dll files was likely to break Windows too much for the user to be able to access the payment methods, or that no-one cared enough about their .bat files to make it worth encrypting them. This also suggests that relying on specific file types not being encrypted is a bad strategy, since it would be trivial for the designers to change these at any point.


"Life is not easy." Linux virus : what to do next?

To add to the above comments:

I used this blogpost (in chinese) instructions to clean the system.

Once your system gets compromised you can no longer trust it in any shape or form. The only surefire remedy is to wipe clean your entire drives.
Also, the above links don't mention it but nowadays, but if we are talking about a personal PC/server malware can infect UEFI BIOS as well, so if I were you, I'd reflash BIOS as well. If your device is some shared virtual server, then simply destroy it and create a new instance.


Can open source software be digitally signed?

While you can sign the software this does not mean that you can store the public key needed for signature validation in the device which should do the verification. Just releasing the public key does not make it magically available on all places which need to do the verification.

In case of SecureBoot the UEFI system which needs to validate the signatures is not open source. And even if it would be open source this does not mean that systems come pre-installed with the key you used for signing. In the existing implementations some vendors allow you to store your own keys for validation and others don't. This means that every user of the signed software has either to disable SecureBoot or add the key you used for signing, if this is possible at all. Since both of these option are too complex for the average user it would be much better if one could use one of the keys already known by the implementation for signing. This of course means that you need to have access to the related private key.

The current workaround in Ubuntu is to have a small shim signed by someone which has access to the needed private key (i.e. Microsoft) and then boot the rest of the system from there. See Ubuntu Wiki: SecureBoot for the technical details.


HPKP could be used for tracking in big scale since it has report URIs:

Send HPKP header with includeSubdomains set and a report-uri with unique random generated parameter.
Embed a hidden image from a subdomain that uses a invalid/not pinned certificate.
Browser calls report-uri with unique parameter.

Only issue I see is a new report-uri with new UID being issued each time the user visits the site that sets the UID.

Also see Privacy Considerations section of the HPKP RFC.


How can I find an unauthorized/unknown proxy on my home network?

You should check whether your current IP is on a proxy list. Since your IP address is assigned dynamically, it could be that the former owner got himself onto a proxy list - these lists get generically blocked by many pages.

It is, however, easier, just to get a new IP and try again.


DNS flood vs DNS Amplification attack: How is one considered a network/transport layer attack and the other a application layer attack?

Yes, you've understood it correctly (except for a few details, see below) and the authors of the survey you've linked to are wrong. Or at least, if they have even really had some bright idea behind that paragraph, they have failed to present it right.

E.g. there definitely exists an approach to classify DDoS attacks based on the vulnerable protocol layer. In that way, UDP flood is a transport layer attack and DNS amplification is application layer, though from the victim's point of view in both cases it's the network layer which gets congested. The real world applicability of such an approach is questionable at best, but the authors of the survey don't even refer to that, they are more practical (which makes me say they have made a mistake).

One possible reason for that is that the paragraph which discusses DNS amplification refers to some articles dating back to 2004. Since that time, quite a lot of DDoS-related events have happened, so it's probably best to find something more up-to-date to read.

My two cents though:

It's more proper to call that "layers", not "levels";
An attacker doesn't actually need bots to do UDP-based DNS flooding. A couple of servers connected to a network with a good bandwidth and no RPF will do the same trick by spoofing the IP source of the packets;
However, a botnet would be useful if the victim is able to do some DNS-based challenges or to simply quickly truncate the response, forcing the client to retry the DNS request via TCP (yes, DNS can operate via TCP).


Is it possible to browse HSTS sites over SOCKS5 proxy?

SOCKS5 by itself just make sure that the necessary TCP connectivity to the target is created and that all data are forwarded between client and server. It also might do a DNS lookup to resolve the hostname. A plain SOCKS5 proxy does not change anything with the payloads or changes the requested target server which means that HSTS will continue to work the same as without proxy.

But what you see here as error has nothing to do with HSTS at all.  ERR_SOCKS_CONNECTION_FAILED means that the SOCKS5 server was unable to create a connection to the requested target. This is a problem creating the TCP  connection already and has nothing to do with HTTPS and thus also not with HSTS.


TL;DR: What you want is not possible due to the way DNS works.
DNS does not work like HTTP where some client accesses a server and where this specific client can be rate-limited by this server. Instead DNS is a distributed directory service, consisting of many authoritative name servers which provide information about "their" domains and additional recursive name servers which collect and cache such information for their clients.
A request to resolve a specific domain will typically not come directly from the client but from another recursive name server which was asked by the client to resolve this domain. This means that there is no direct relationship between a DNS request received by the authoritative name server the and a client: the same client might use different recursive name servers so that the source of the request at the authoritative name server differs. And many client will usually use the same recursive name server so that any rate limiting will affect many clients and not only the specific client one likes to slow down.


Are there theoretical attacks against ECC Digital Signatures?

A couple of pitfalls with ECC:

Invalid curve attacks: Attacker encodes a point which is not on the curve and has low order. Deadly attack on Diffie-Hellman. I don't think this can be exploited with ECDSA since there is no attacker controlled point.
Point on twist on a non twist secure curve: Same as above, but works for compressed points as well.
Incorrect handing of special cases: Traditional ECC addition formulas need to handle several special cases. It's easy to forgot one.
(EC)DSA needs a uniformly distributed per-signature value. Using the same value twice or using a guessable value leads to key recovery. Even a small bias can lead to key recovery if enough signatures are known by the attacker. RFC6979 describes a deterministic generation method.
Applications relying on unusual properties the signature scheme doesn't provide. For example signatures are malleable, which caught some bitcoin applications by surprise.


Opening ports, especially to untrusted networks can have a number of risks (one of which, as you've correctly identified is 0-day vulnerabilities)

Depending on the service that's listening the configuration could be a larger source of concern. Things like default or easily guessable credentials are the source of many security issues and these are generally quite easily exploited as the information about what the default usernames/passwords for various services are is easily available.


HMACSHA512 versus Rfc2898DeriveBytes for password hash

Rfc2898DeriveBytes implements PBKDF2: a function which turns a password (with a salt) into an arbitrary-length sequence of bytes. PBKDF2 is often used for password hashing (i.e. to compute and store a value which is sufficient to verify a password) because it has the needed characteristics for password hashing functions: a salt and configurable slowness.

These characteristics are needed because passwords are weak: they fit in human brain. As such, they are vulnerable to exhaustive search: it is feasible, on a general basis, to enumerate most passwords that human users will come up with and remember. The attack assumes that the attacker got a copy of the salt and the hashed password, and then will "try passwords" on his own machine. That's called an offline dictionary attack.

In your case, you have a third element: a validation key. It is a key, i.e. supposedly secret. If the attacker could grab the salts and hashed passwords but not the validation key, then he cannot perform the dictionary attack on his own machines; under these conditions (the validation key remains secret, and the validation algorithm is robust -- HMAC/SHA-512 is fine for that), the configurable slowness of PBKDF2 is not needed. This kind of validation with a secret key is sometimes called "peppering".

Note, though, that when we assume that the attacker could grab a copy of the hashed passwords, then it becomes a matter of delicacy to suppose that the key remained unsullied by his vile glances. This depends on the context. Most SQL injection attacks will be able to read part of all of the database, but not the rest of the files on the machine. Nevertheless, your server must somehow be able to boot up and start without human intervention, so the validation key is somewhere on the disk. An attacker stealing the whole disk (or a backup tape...) will get the validation key as well -- at which point you are back to the need for configurable slowness.

Generally speaking, I would recommend PBKDF2 (aka Rfc2898DeriveBytes in .NET) over a custom construction, although I must say that you appear to use HMAC properly (homemade constructions rarely achieve that level of correctness). If you insist of having a "validation key" (and you are ready to assume the procedural overhead of key management, e.g. special backups for that key), then I suggest using PBKDF2 and then applying HMAC on the PBKDF2 output.

See this answer for a detailed discussion on password hashing.


Is a MitM (Man in the Middle) attack by definition an altered or injected communication on an encrypted communication?

Short answer - no, man-in-the-middle attacks are not necessarily confined to encrypted communications.

Also, in many cases MITM on encrypted connections is aimed at actively intercepting/eavesdropping on messages, rather than injection. One example are some Intrusion Prevention Systems (IPS) (e.g. PaloAlto do it for SSH) that need to perform MITM in order to inspect traffic content, which otherwise would pass through the IPS w/o being fully examined.

On your second question of verifying the authenticity of a message, one does not have to exchange messages over an encrypted medium, but can use methods such as digitally signing messages (for example, using PKI) - the message can be sent in plain text, and the attached message fingerprint (cryptographic signature) can prove its authenticity.


Who is talking to my laptop? No PCAP or firewall-- in BYOD environment

An easy way to log any incoming (or outgoing) connection attempts is to use IPtables. IPtables has the ability to log arbitrary information to the syslog. An easy way to accomplish this is to set up a rule in the INPUT chain that sends all unaccepted traffic to a new LOGGING chain, which will output those packets to syslog and finally drop them.

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Then, you could watch your syslog with:tail -f /var/log/<log_file> | grep IPTables-Dropped
Source: http://www.thegeekstuff.com/2012/08/iptables-log-packets/?utm_source=feedburner


What's the best way to securely obtain and submit a Malware Sample for analysis?

I don't think you have to worry about malware running from within the clipboard, unless you're manually pasting commands in an attached file into your terminal.

I guess they could try to read/write to the clipboard via some browser, see here https://stackoverflow.com/questions/5551338/how-to-read-clipboard-data-in-cross-browser

On a more serious note, a general rule of thumb when dealing with malware is to do so in an isolated environment, such as within a virtual machine with limited access to its host, and if it has an internet connection, maybe add firewall rules so that it can only ever connect to a white-listed analysis website.

One of my favorite "hacking" scenes in any movie was in the bond movie, Skyfall. In the film, the young and (apparently) foolish Q decides that it is perfectly safe to plug in the villain Raoul Silva's laptop into MI6's network with a direct connection to his personal work machine. And then they wondered why Silva was able to hack them in the first place...

As you've probably discovered, whenever you're dealing with a foreign object on a network, the best way to deal with it is to keep it quarantined. Whether that means ignoring spam emails or trying to open them in a virtual environment is up to you. Personally, I'd opt for the former.


Do Chrome and Firefox send random values rather than the actual timestamp in ClientHello of TLS?

Yes, this is by design. The actual time is not important to TLS, and was only added to the ClientHello by the protocol as a protection against bad random number generation impacting the rest of the random data required as a part of the message.

Since it is not important, the protocol specifically states that it is not required to be the correct time*. The makers of some browsers have therefore decided to randomly skew the time portion of the random element in each ClientHello message they send.

A main reason for this is to aid in preventing tracking, an impetus which came from Tor - see the Mozilla post about this decision.

*RFC 2246/5246 § 7.4.1.2. Client hello:

  Clocks are not required to be set correctly by the basic TLS Protocol;


Credit department is asking me to email them a color copy of my US social security card - how unsafe is this?

I would recommend that you do not include a color copy of your U.S. social security card in this matter. Even if they say that it is a secure transaction, it would be safer to assume that it is not. Email servers get compromised all the time. It would be incredibly risky.

One red flag in this email is them rushing you to send it: this is not typical, and sounds like a phishing attempt. The subject line URGENT ACTION REQUIRED and threatening an undesired action if you do not comply within a strict time frame is a sign of this.

In addition, I'm not sure what avenue you could take to even verify that is indeed Mercedes-Benz. I would locate a number independent of this email to phone Mercedes-Benz and ask about this kind of email. They should be able to accommodate your request based on security concerns. If they do not, like ISMSDEV said, its up to you whether or not take this risk if this is the only method they will allow.


How to reduce the risk of sudo vim -Z (sudo rvim)

Instead of running the vim in privileged mode and then mitigating vulnerabilities arised from it, what about just using correct file permissions? If plain UNIX permissions are not enough, you might want to use ACL.

Since users can do arbitrary file modifications in vim and they will not have to use sudo, I don't see any important security or comfort advantage of using sudo. (Except that users can be forced to re-enter the password.) On the other hand, permissions are just simple, user can choose its own editor with any settings (just for comfort, not for security) and it is clear there are not general pitfalls with permission escalations. (It, however, depends on files allowed ti edit.)