Do I need an SSL Certificate for a HTTP only site?

If the certificate is there, then chances are that it is used for something, and that something will probably break when the certificate expires.

In your case, if you use pure NTLM, then it seems that no certificate is used at all, so maybe you can let the certificate die and see that nothing happens. However, authentication in SharePoint can be complex so I won't claim to give any definite guarantee here.

Note, though, that the NTLM protocol is vulnerable to offline dictionary attacks: someone observing the traffic won't see the passwords "as is", but will learn enough to "try passwords at home" at a rate limited only by the number of PC that the attacker can muster -- and that will be counted in dozens of millions per second. Not many user-chosen passwords last long under these conditions. And, of course, a HTTP-only site is easy prey to attackers: if you use authentication, then you fear unauthorized accesses; if the data is confidential then a passive eavesdropper will see the data as it is retrieved by normal users; and an active attacker can hijack connections at will (that's the classic Man-in-the-Middle: the attacker forwards bytes in both direction, and when the authentication has been done, he takes control of the connection).

In simple words: if you really need some security in your case, then it seems highly implausible that you can get away with not using SSL. And if you do not need some security, then why are use using authentication at all ?


Is it possible for a phone to be transmitting even while turned off and the battery removed?

If you have a phone with a removable main battery, you can try this:

Disable the cellular network, GPS, WiFi, Bluetooth etc on your phone by turning them off manually and then putting the phone into flight mode.

Make a note of the current time shown on the phone and on your PC by writing it down on paper.

Shut down the phone, remove the main battery and the SIM card. Now wait 5 minutes.

Put the main battery back in, but not the SIM card and then turn the phone on again. The phone should still be in flight mode.

Note the current time on the phone again and the current time from your PC.
Remember when in Flight Mode and without the SIM card, the phone cannot get a time update from the cell tower. If a phone just stored the current time in flash memory before shutting down, then on powering on the phone it would be 5 minutes behind and match the time you wrote down on paper. This is because it would not know how much time had elapsed from when the phone had shut off and when it was turned on again. However that is not what happened, it kept up with the current time even when shut off and the battery was removed. That is because of the second battery on the phone.

This HowStuffWorks article looks into the inside of a digital mobile phone. Quoting from the article: "As you can see in the picture above, the speaker is about the size of a dime and the microphone is no larger than the watch battery beside it. Speaking of the watch battery, this is used by the mobile phone's internal clock chip." This would be similar to the function of a CMOS battery in every PC/laptop. There is also a February 2010 patent mentioning a primary and secondary battery of different size and capacity: "The first battery may discharge during use of the mobile phone without simultaneous discharge of the second battery. Upon discharge of the first battery, the second battery may not be automatically activated."
A standard silver cell watch battery has a capacity of 200 mAh, a Zinc-air battery has a capacity of 620 mAh. From personal experience, my battery in my wristwatch has lasted for over a decade as it was just keeping the time, running alarms and the odd stopwatch. I am not certain which capacity the secondary battery is which is installed on most mobile phones but it could contain a newer, powerful one installed by the manufacturers. The design of mobile phones is typically a closed design. There is a new micro-battery that could fit in and power a credit-card-thin device and be charged 1,000 times faster than regular batteries. Therefore every time you charged your phone, it would charge the secondary battery as well.
When the phone is turned off and the main battery is removed, the secondary battery could do more than just keep track of the time. It is all connected to the same circuitry so it could leave certain chips powered on in a low power state, for example the GPS, the microphone, the camera, or the closed baseband processor on every mobile phone.
Now, hypothetically the secondary battery could be remotely activated and periodically do a burst transmission every x minutes and send GPS coordinates or microphone recordings back to your favourite 3 letter agency. If the chips were just passively transmitting, perhaps they need a StingRay or Reaper drone in the area to boost the signal. The cell tower itself may be powerful enough to pick up the signal.
This article states that the NSA can technically listen in to the microphone of an iPhone even if it is switched off. In Edward Snowden's conversations with Laura Poitras he advised her to put her mobile in the freezer. In Snowden's NBC interview he mentions "They can absolutely turn them on with the power turned off to the device". He even took out the main battery in his phone before a recent Wired interview. Removing the main battery may not be enough to avoid surveillance.
If I add a thick layer of tinfoil to my hat, perhaps everyone's mobile phones have been converted to an always on bugging and tracking device by NSA. They could have bugged every phone and home in the world whether their phones were turned on or not. You could get intel on anyone, anywhere. This could be why NSA does not allow mobile phones in their secure environments. It could activate every time it picks up speech then do a burst transmission at certain intervals. Maybe it only does that if you mention certain key words but maybe the phone does not have that capability with only the second battery running. Usually that analysis usually takes place in the basement of Fort Meade.
I would not be surprised in the slightest if there was a big black screen system with a map inside the NSA with coloured dots all over it. The green dots would be the people with their cellphones turned on and transmitting audio and GPS coordinates back to NSA. Then the orange dots would be people in "flight mode" or who have turned their phone "off", but their phone is still communicating with the tower. Then blinking orange dots for people who have turned their phone off and removed their SIM card, but their phone is still trackable by the unique IMEI on their device. Then red dots for people who have turned their phone off and removed the main battery. Highly suspicious behaviour obviously. A Reaper or StingRay would then be dispatched to the red dot's location.
How would you potentially stop surveillance from our mobile phone even with the battery removed?

Open the phone and remove the secondary battery. This may be difficult if the battery is hardwired to the circuitry and could damage the phone. This will definitely void the warranty as well.
Use a Faraday cage for when you want to go 'off the grid'. Some retailers are selling this as a small pouch or bag you can put your phone in. The effectiveness of this has not been tested.
Do not take your cellphone to places where you do not want to be found.
Destroy your cellphone and get a fully open source WiFi only device (if such a thing exists). Only turn on the WiFi when you want to connect to something. This means no closed source secondary operating system running the closed baseband processor, no GPS and no cell tower connection. You could connect out through various WiFi hotspots using a VPN or Mesh networks instead.

As Brill would say,
"The more technology you use, the easier it is for them to track you."


How does an attacker authenticate to a service using just the hash of the user (after performing a "pass the hash"-attack)?

In a pass the hash scenario there is no salt mixed in with the password when a user authenticates, because of this an attacker can get the hash of the users password when they authenticate to a service and then pass it along to authenticate to more services that use the same authentication scheme without knowing the password. NTLM is an example of a authentication scheme that is vulnerable to this.

https://en.wikipedia.org/wiki/NT_LAN_Manager


How can the NSA remotely turn on your iPhone?

You make some wrong assumptions : "how can it be remotely turned on if no software is running and network communications aren't even activated until the device boots".

There are two computers in your average smartphone, the one that you more or less control, running e.g iOS or Android, and a second one, the Baseband Processor, handling radio communication with the carrier network. It has its own processor, its own memory, its own operating system and what its exact capabilities are is usually a trade secret. You have no reason to think it is actually off if it actually has access to a DC source, in this age of non removable batteries it should be at all time unless the battery is completely drained. Presumably the NSA got a good relationship with the american makers of such chips (e.g. Qualcomm), with the expected consequences, but they will deny it vehemently. They also possibly planted or found exploit for many chips whose maker are less susceptible to direct influence (e.g. Korean and Chinese ones). Your cellphone (well, the part that you control) is never talking directly to the carrier network, it talks to its baseband processor.

There have been some attempts to reverse engineer some chips, see e.g. Reverse engineering a Qualcomm baseband but you are unlikely to find an obvious backdoor here, more likely a subtle, well hidden vulnerability waiting to be exploited but being plausibly deniable.

WTS, Faraday cage, good price.


Preventing fraud in bitcoin mining pools

Idea One: Even if possible, when he submits the block to the blockchain himself, the payout still would go to the mining pool. The payout address is part of what is being hashed.
Idea Two: The pool wouldn't know to payout your share either in that scenario.


Both passwords may decrypt the file,  but only one password will yield the correct plaintext.  The zip encryption format is just checking to see if the padding is correct to verify that the correct key was used.   The password 79095 produced valid padding,  however the resulting message is garbage.


NIKTO: Requires Authentication for realm ''MD5''

As Nikto's README.md point out; The parameter for host authentication -id's format is:

id:pass or id:pass:realm

You can probably try this: nikto -id id:pass:MD5 -h xxx.xxx.xx.xxx

Also, you can find here the authentication plugin's code (written in Perl), and here the Wiki of this project.


dnsspoof not spoofing (requests and forwards real DNS packet)

Try installing libpcap0.8 and libpcap-dev. There was a bug and this should fix it, although it didn't work for me. I use kali on my tablet with a Linux deployment and there are many issues.


Sensitive data transmission over Internet

Is the security level of current widely used application such as WhatsApp, Telegram or Facebook Messenger sufficient for us to transfer the sensitive data? I believe this method is the most widely used by public users now.

Facebook Messenger and Telegram doesn't use end to end encryption by default. Your data is encrypted during transmission, but Facebook and Telegram can read your messages while it passes through its servers and they store your messages as well. Both Facebook and Telegram supports end to end encryption, but this is not default. You have to turn on Secret Conversation/Chat to enable end to end encryption. WhatsApp uses end to end encryption by default, so WhatsApp is much more secure than either in its default configuration.

However, users that wishes to use any of those services for transferring highly sensitive data need to take extra steps beyond default. In particular, in addition to enabling end to end encryption, you need to verify the other party's encryption key out of band, because otherwise you may be using an end to end encryption to talk to your adversary rather than your intended recipient. Also, Telegram have also been criticized for developing their own encryption scheme, instead of using well known secure ones. WhatsApp also has been the subject of some criticism in the way it can do transparent rekey and resend, which may leak some of your most recent messages.

Among the major encrypted instant messaging software, Signal is probably the one that's garnered the least criticism in its implementation of end to end security. WhatsApp and Facebook Messenger's end to end encryption protocol are based on Signal's protocol. All of Signals' clients and server implementations are open source, and the Signal Protocol is based on long respected cryptographic primitives. It's one of the few messaging apps that achieved perfect score on EFF's instant messaging score card.

  Is the encryption feature (PGP) in email secure enough to transfer our sensitive data?

There's no known vulnerability in the basic protocol of PGP encryption as of yet. There are from time to time implementation issues like how some features of HTML mail clients interacts badly with PGP and can thus be used to leak information (EFAIL attacks). Most of the latest mail clients have patched these issues. The base cryptography itself is still solid as far as we can tell.

As to whether it's secure enough, you will have to decide, based on the sensitivity of your data and your threat model. If your main concern is preventing leaks from common petty criminals, pretty much any of these services should be secure enough. If you're talking about targeted attacks from government agencies, especially hostile governments, then not all of the services above are sufficient, and you likely need to make changes in the rest of your online habits, not just your messaging service.


You should always:

Remove his/her SSH-Key
Change all passwords he knew
Lock all his/her accounts on all services
Give certain services extra attention, e.g. mail forwarding rules

Some other measures you should consider, depending on the circumstances,  how much you trusted him or her and your resources:

Let another person with the same knowledge check if the leaving person installed any backdoors on workstations or servers.
Run routine scans for vulnerabilities you took as inexistent and which can be created on purpose in a short time, like SQL-Injection possibilities.
Check all workstations and servers he had access to physically for keyloggers and other malicious hardware.
Change the locks the person had keys to, you can't know if copies were made.

As a precaution it's good to synchronize HR with IT. Make sure that one person can de-activate all accounts at the moment the employee leaves his workstation to go meet with HR. At the very least change his passwords to stop him from accessing the network as he exits HR.


Accidentally Shared my Private Key - How to Remedy?

Simple solution would be to discontinue the use of the existing key pair, generate a new Public / Private key pair and deploy them in place of the old ones.


The ciphers are considered weak by SSLLabs since they use RSA key exchange which provides no forward secrecy. To disable RSA key exchange in your ciphers add !kRSA. In general, just use the Mozilla SSL Configuration Generator to give you a secure setting.


Reading/Writing content of files - what can happen?

If I understand what you are doing correctly this is a database implemented as services.  If the data is sensitive a lack of authentication can lead to significant security issues.  Users could read each others data, overwrite important data, and possibly copy all the data in some massive security breach.

In addition to the authentication issues you may have issues if someone wants to perform a Denial of Service attack on your site.  Without proper controls a flood of data could be written and fill up a disk that the server relies on.

Depending on how the data is retrieved (if the requests aren't sanitized) the user could use constructs such as path seperators to downloads important files on the Operating System (/etc/password for example).  If the user is in control of the name of the file being written in anyway they could also use path exploits to overwrite sensitive files allowing them access.


How can I assess the trust worthiness of a browser add-on?

I use the Greasemonkey extension for Firefox. It allows to write small "user scripts" that Greasemonkey injects into the specified websites.

There is a repository of user scripts at http://userscripts.org/ Most of them are really small and easy to understand.

There is a popular script for video downloads from youtube. It is a lot more complex than usual scripts but seems fine on a quick glance. There are many more simpler scripts through.


What can an attacker do to a shared hotspot

It should be safe since it creates a password. But ensure that you use WPA2 instad or WEP. It's more secure. WEP can be broken more easy with brute-force attack. Check the man pages, it is the password keyword.


Voting systems are "gamed" by people voting more times than should be normally allowed (e.g. voting several times). The only way to prevent this is to have a way to identify voters and to prevent multiple votes.

Reliable methods entail authenticating users, e.g. with passwords, but this has two drawbacks, namely that 1. users don't like it, and 2. this does not really solve the problem, but moves it to a prior "registration phase".

Unreliable methods are about heuristically detecting frauds by tracking IP addresses (but this fails with dynamic IP address -- a user can change his IP, and this happens more or less automatically with many ISP -- and also with NAT -- several distinct users sharing the same IP) or with other methods. Simply sending an "has voted" cookie in the user's browser will deter the basic, low-tech wannabe fraudsters; there are more thorough methods, but all of these can be circumvented by a technologically savvy attacker. Tor is a tool which deals with anonymity, a closely related subject, and shows that you are trying to fight a losing battle.

StatckExchange itself faces the same issue, which it calls sock puppets. They finally took a relaxed attitude, with (unpublished) scripts for detecting the most blatant gaming attempts, and mostly ignoring the rest.


Want to implement a really good authentication mechanism for REST API

Don't roll your own auth, Json Web Token (JWT) can do what you want, it is simpler than oAuth and uses HMAC


Do opensource rootkits exist for Android?

Yes. I suspect there are also others that may be more feature-rich. Searches for these in other languages may also be useful for finding others.

https://github.com/hiteshd/Android-Rootkit

Although not technically open source you may want to look at the Hacking Team dump that was in the news a while back some of the code from that may be of interest to you.

https://github.com/hackedteam?tab=repositories


JKS - Keystore protection and configuration file

As @whoami mentioned, it does just move the issue to another place. As you mentioned it allows you to move it out of code (if you've hardcoded it), password protect it (if it was originally just a PEM or whatever on disk), and ACL it to the requisite permissions.

The problem is that you do need to know the key to unlock it, and that of course requires protection of some sort, and well, you get turtles all the way down.

What you're basically doing is moving the bar for the attackers so they have to put in more effort to break the thing. At some point they just say screw it, and move on. You can make it harder by introducing complexity to key generation, but if attackers know how this works they can do it themselves easily enough, or worse they can just steal the file and try brute forcing the key since its not particularly random. In some cases the OS does provide a mechanism of protecting the random keys, but in this case you'd need something that is exposed to the JVM.

More practical solutions involve moving the key to better-protected areas, and that usually means hardware of some sort. In some cases we're talking TPMs, HSMs, or simply smart cards (though they are all really the same thing, but with different features). The basic principle is that the key never leaves the hardware, so its impossible to steal it. A side effect of this is that all crypto usually occurs in the hardware itself, so all you're doing is shoving data in, and getting data out, without needing to worry about the crypto itself.

This then means you need to protect the interface to the hardware so only authorized systems can talk to it. See the turtles yet?


Active Directory DNS server security misconfiguration or an acceptable practice?

This should definitely be reported to your CSO and/or his/her team.

Besides you being able to add DNS records, chances are good, that you can execute other commands as well to manipulate the DNS configuration. From my experience it is better to report findings like this fast.

If the network administrators in charge notice the alterations that you have made, they will most likely be able to trace them back to you. If you have not reported this incident to them by then (or even in a timeframe that acceptably small), this will put you in a far worse light than reporting the issue in the first place.


Is there any drawbacks of "accepting all cookies" while in incognito mode?

If the only concern you have is tracking cookies, the only downside I see is that cookies aren't cleared until you close the incognito session, so they could still be used to track you across sites during that session.

As an alternative, there are also browser extensions that clear cookies after leaving a site, but only for sites you haven't whitelisted.


Is this somebody trying to exploit a vulnerability?

Do you write in logs which session IDs are generated?

Maybe 'good' user got this session id from your application, but then application 'forgot' about this? (because session expires or because application was restarted, server rebooted)

Simple guessing sessions id few times isn't very good way to hack site, maybe some tool like Splunk could greatly help you. (e.g. it can show that 99% of invalid session id error comes from requests from single IP - then it would really be suspicious).


If you know/guess the server file system information then you can try loading local system image file by giving file path in

  xlink:href="localPathOfImage"

As this is SVG file then you can try checking XXE, Billions Laugh attack etc


Could someone commit a social engineering "hack" on a credit card processor to get my credit card number?

Your question is very broad and your title does not match the text of your question. Processors have taken steps to reduce access to this data but there are regular breaches of credit card data so yes, what you ask in your title might be possible.

To clarify your checksum statement.  Credit card numbers adhere to an algorithm (called the Luhn algorithm) to help various parties check if it is a valid card without actually running it.  It is meant to prevent errors as opposed to attacks.  In some ways, this makes it easier to brute force as an attacker could easily generate the subset of numbers that pass the algorithm.

No, You cannot generate the full credit card account from a receipt.  Receipts often show the last 4 digits of the account number and that would of course help the brute force attempt above.

US law says no more than 5 digits can be shown on receipt.

You said the first digit was used to identify the issuer.  Actually the first 6 are the Issuer ID Number and are public domain.  PCI compliance allows for the first 6 and last 4 to be shown.

Fraudsters buy and sell lists of known full accounts or implement brute-forcing schemes that do not involve fishing receipts out of the trash.

Someone targeting you personally might find the receipt valuable.  As they commented in the article you linked to, some companies used to (and maybe some still do) use the last 4 digits to validate your identity.


Nothing prevents ads from reading your passwords.

Ads (or any other script like analytics or JavaScript libraries) have access to the main JavaScript scope, and are able to read a lot of sensitive stuff: financial information, passwords, CSRF tokens, etc.

Well, unless they're being loaded in a sandboxed iframe.

Loading an ad in a sandboxed iframe will add security restrictions to the JavaScript scope it has access to, so it won't be able to do nasty stuff.

Unfortunately, most of the third-party scripts are not sandboxed. This is because some of them require access to the main scope to work properly, so they're almost never sandboxed.

As a developer, what can I do?

Since any third-party script could compromise the security of all you personal data, all sensitive pages (like login forms or checkout pages) should be loaded on their own origin (a subdomain is fine).

Using another origin allows us to profit from the Same-Origin Policy: scripts running on the main origin can't access anything on the protected origin.

Note: Content Security Policy and Subresource Integrity could also be used if the third-party can be easily reviewed, but most ad networks couldn't work anymore if you used them.


Is a Diffie Hellman Ephemeral key good material for being used as a symmetric cipher algorithm key?

DH (be it with elliptic curves or not) results in a shared secret. That secret is a numerical value with some algebraic properties; however, all the secrecy is contained in it. You just need to distill it, the same way you turn potatoes into vodka.

Suppose that you are using a 256-bit elliptic curve, e.g. NIST's standard P-256 curve. The elements sent over the wire are curve points, each being, formally, a pair of coordinates (X,Y) in a 256-bit field. The DH result is another curve point, and, per the standard, the X coordinate of that final point is the shared secret. It is a 256-bit value. With such a curve, ECDH is supposed to offer "128-bit security" (which is good), so the shared secret somehow contains 128 bits worth of secrecy. That secrecy is "spread" over the actual 256 bits. So there is room for structure as well in that 256-bit value.

Using the resulting 256 bits "as is" is usually considered unwise because it is not easy to determine the extent of that extra structure, and how it could be exploited externally. To turn these 256 bits into a sequence of bits that you may truncated and split into keys for AES/HMAC/whatever, the simplest method is to hash them with some hash function. E.g., apply SHA-256, and you get again 256 bits, which can then be safely split and used as you wish. For a more generic case, use a key derivation function.

As for the curve choice: since there are performance benefits to hardcode the exact curve in the implementations, most existing libraries will support only a handful of specific curves. In SSL/TLS, when using elliptic curves, the client sends a list of symbolic designations for the curves it supports, and then the server chooses one of these curves. In practice, everybody uses P-256. Of course, in a custom protocol, you can choose some other curve; you could even mandate that arbitrary curves may be used, dynamically, but then you would have to make provisions for sending the curve parameters, and this will be burdensome for implementations since most EC libraries don't offer support for arbitrary curves.


Does client side encryption really add security?

Client-side encryption does not protect against a malicious trusted application provider who decides to subvert their own system.

It does protect against attackers who breach the central store.  Those people cannot decrypt without keys, and if the provider doesn't have the keys (the key feature (sic) described above), then the attacker can't steal those in the same manner.  They'd have to compromise both the central store and the user endpoint(s), making a compromise of your data that much harder.

So does it really add security?  Yes.  Not for every use case, but for the use cases that realistically are a greater threat and a higher likelihood.


Is the connection to Tor hidden services encrypted?

Tor exit nodes aren't involved in the connection to hidden services. Exit nodes are only needed when you want to exit the Tor network in order to connect to some website outside of it. In the case of connecting to hidden services, all the traffic stays inside the Tor network.

In the following illustration, you can see how Bob (a normal user) is trying to connect to Alice (hosting a hidden service). As you can see, the connection happens through a Rendezvous point (RP) inside the Tor network.

[image from torproject.org]

All traffic inside the Tor network are encrypted and secured with TLS tunnels.


Will typing my password twice make it more secure? Or typing each character twice?

Let's try skipping theory and going straight to practice.

Will typing the same word twice (or N times) substantially help?

John the Ripper Jumbo has a variety of "simple rules" about this

d duplicate: "Fred" -> "FredFred"
f reflect: "Fred" -> "FredderF"

oclHashcat rules based attack has simple rules just for this, too

d  Duplicate entire word   d   p@ssW0rd    p@ssW0rdp@ssW0rd
pN     Append duplicated word N times  p2  p@ssW0rd    p@ssW0rdp@ssW0rdp@ssW0rd
Reflect    f   Duplicate word reversed     f   p@ssW0rd    p@ssW0rddr0Wss@p

Therefore, no, this bit of cleverness is so common it's included explicitly in both common rulesets already for use by itself, or in combination with other rules.

OR type every character twice

John the Ripper Jumbo has an example specifically about this in the documentation

XNMI extract substring NM from memory and insert into current word at I is the core rule
"<4X011X113X215" (duplicate every character in a short word) is the example in the documentation to cover exactly your case for short passwords

.

oclHashcat rules based attack has simple rules just for these kinds of attacks

q  Duplicate every character   q   p@ssW0rd  pp@@ssssWW00rrdd
zN   Duplicates first character N times   z2   p@ssW0rd   ppp@ssW0rd
ZN   Duplicates last character N times   Z2   p@ssW0rd    p@ssW0rddd
XNMI  Insert substring of length M starting from position N of word saved to memory at position I    lMX428    p@ssW0rd     p@ssw0rdw0

Therefore, no, again, this is such a common bit of cleverness that it's called out explicitly in both major open source cracking products.

Assume that it is already 8 or 9 characters, consisting of upper and lower case, digits and one or more special characters.

The other rules in those products very likely cover everything you're doing already, and it's also likely that whatever combination you have is already included in a ruleset applied to a reasonable cracking wordlist.

oclHashcat alone comes with twenty five different files full of .rules, including d3ad0ne.rule with more than 35,000 rules, dive.rule with over 120,000 rules, and so on.
a large number of wordlists are available, some of which may include your exact password - the Openwall wordlist alone has a single 500MB file of more than 40 million words including mangled ones
and I'm personally aware of both small, very good wordlists (phpbb, et all) and huge, comprehensive wordlists with literally billions of entries, taking up many gigabytes of space total.

As with everyone else, you need to use try randomness or something like an entire sentence worth of personal anecdote that does NOT use words in a top 5000 list of common English words, and does use long, uncommon words (to force combinatorial attacks using much larger dictionaries).

Specifically look, for example, for words selected at (good) random included in Ubuntu's insane english ispell dictionary list that are not included in the standard english ispell dictionary, for example.


TLS 1.0 Deprecation and Mitigation Tactics

"You need to upgrade" is absolutely a valid response. TLS 1.0 was defined in 1999 and has been around for 20 years now. TLS 1.2, which is considered secure by today's standards, has been around since 2008, which is plenty of time for even slow companies to migrate to it.

But version numbers alone isn't what gets managers to order an upgrade of their ancient systems. It's a cost/benefit analysis, and in this case it's very simple:

Sticking with TLS 1.0 is a high security risk. Several well-developed attacks against TLS 1.0, such as POODLE or BEAST, exist. If the servers are not upgraded, they risk their e-mails being compromised.

Personally, I would consider supporting provably weak cryptography a security risk. And engaging in such a security risk - especially when there have been so many warnings that you should upgrade - just because some company is unwilling or unable to so, is difficult to justify.


It is the server's responsibility to serve up the entire certification chain.  If your web server isn't doing that, it is misconfigured, and you should fix it.

You can use the SSL test service from SSL Labs to test whether your server has SSL properly configured.  Just type in your server's domain name, and it will give you a report indicating whether it has any configuration issues.  You can also use GlobeSSL's SSL tester, if you want a second opinion, though I think SSL Labs' service is more comprehensive.


Is exposing the server time a security risk?

The server time is of little use to an attacker, generally, as long as it is accurate. In fact, what is being revealed is not the current time (after all, barring relativistic physics, time is consistent everywhere) so much as the time skew. Note that, even if you do not explicitly reveal the time, there are often numerous ways to get the local server time anyway. For example, TLS up to and including version 1.2 embeds the current time in the handshake, web pages may show the last modified dates of dynamic pages, HTTP responses themselves may include the current time and date in response headers, etc.
Knowing the exact clock skew of a server is only a problem in very specific threat models:

Clock skew can be used in attacks to deanonymize Tor hidden services.

Poorly-written applications may use server time to generate secret values.

Environmental conditions of the RTC may be revealed in contrived situations.


How can I prove that my software is secure for those who are interested to install it?

Prove is a strong word, and to be honest, it isn't the word you're looking for.  What you really want is trust.   You want users (or potential users, in this case) to trust that your software is secure enough for them use to protect their most sensitive data.   There are several ways that you can do this.

Open source the software.   If users have the ability to review the source code, technical users are more likely to trust it, even if they never do review the source code, or in many cases are not even qualified to review the source code.
Get an independent opinion from a qualified third-party.  In other words, an audit that gives your software a clean bill of health.
Professional presentation.  If your software is on a website that looks like it was built by an amateur in his spare time, many people will ascibe to it that quality for all of its features, including security.  If it's presented professionally, and looks to be backed by someone professional, correctly or not, people will think more highly of it.  Such is psychology.

Ulimately, your biggest challenge is likely not in your offering itself, but in the competition.  There is a lot of password manager software out there.   Yours needs not only have to appear to be of high quality and secure, but at least as high quality and secure as theirs.


Is an OpenPGP signature made before a key is revoked considered valid?

The short version: there is no way to differentiate between signatures issued before and after revoking a key. Faked system times and how attackers could exploit them provide a rather obvious explanation for this.

The slightly longer version with interactive exploration: RFC 4880, OpenPGP does not specify any rules on how to handle signatures issued by revoked keys -- apart from the sentence "A
revoked key is not to be used". The behavior in this case is implementation dependent. The most common implementation is probably GnuPG, so let's try how GnuPG acts. Consider following situation:

created keypair A in home directory A
signed a test document with this key
exported public key A
imported public key A into home directory B
created keypair B in home directory B
signed public key A with private key B

We now have a non-revoked key A, a document signed by this key, and this key A is certified by some other party B (and thus the key and its signatures validate successfully).

Now, what happens if we revoke key A (after signing the document)?

gpg: Signature made Wed Nov  1 15:39:35 2017 CET
gpg:                using RSA key 658787F11DEFDEE1DA206171C2F6C4CC6B298CA6
gpg: Good signature from "A" [full]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: Key is superseded

What happens if create another signature after revoking A (I took a copy GnuPG home directory A before revoking the key), so B tries to verify a signature issued by an already-revoked key?

gpg: Signature made Wed Nov  3 15:42:31 2017 CET
gpg:                using RSA key 658787F11DEFDEE1DA206171C2F6C4CC6B298CA6
gpg: Good signature from "A" [full]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: Key is superseded

With other words: you cannot discriminate between a signature issued before the revocation and one issued after. And this is a reasonable solution: as no third-party timestamping was involved after all, you cannot be sure about the signature's timestamp anyway. In fact, I also faked the system time when issuing the second signature. "Does OpenPGP key expiration add to security?" provides a similar discussion.

Waiting some time might be useful, anyway: for example if you provide a key transition statement, waiting for some time after issuing this (and notifying your peers about it) before revoking the old key might be reasonable. By doing so, people still see the non-revoked old key and can sign your new key, if their signing policy allows this.


First of all SSL without a certificate is not possible, don't try to roll your own security because you will fail at it. You might think "hey how would you not know that I'm actually a very good crypto expert" well because you wouldn't be making such statements.

PCI-DSS is only mandatory if you are processing credit card data. This means that if you accept and store credit card information, you are required to be PCI-DSS compliant. What if you are not compliant?
Well according to this reference:

  If you do not meet the PCI standards for compliance and the security
  of your site gets compromised, you will be facing penalties and fines
  ranging from $5,000 to $500,000. The fines, however, are just the
  beginning of the overall damage caused by noncompliance.

  If your website or company are not PCI compliant, you run the risk of
  losing your merchant account, which means you won’t be able to accept
  credit card payments at all. You will also be placed in the
  Visa/MasterCard Terminated Merchant File (TMF), making you ineligible
  to obtain another merchant account, at least for several years. The
  TMF, is essentially a BLACKLIST from which it is almost impossible to
  be removed.

  When a merchant is added to the TMF, sometimes called The Match File,
  their name, business name, business address, and home address are all
  noted. So, you can’t just apply for a new account under the name of
  another family member or business partner because it will be seen as
  the same business and location.

  Getting on The Match File is just about the worst thing that can
  happen to any merchant.

Now as you read there is a fine, just FYI the fine comes ontop of all the fraudlant charges (which you will be held accountable for as well).

If you're thinking, "how can I make a business if I can't accept credit cards?" quite simply by using a payment gateway such as Paypal which takes care of all payments (and thus also takes away your need to be PCI-DSS compliant).


Are client generated CSRF tokens as secure as server generated ones

The actual answer to your question depends entirely on how the token is generated and used. In some cases, doing it server-side is a necessity if you don't want to trade away other security. In other cases, it makes no difference.

There is only one important part of "generating the CSRF token in the JS code and sending it as cookie and header" and it's the "header" part. You can't send custom headers (or standard headers with any but a narrow set of values) in cross-site requests, unless CORS is specifically configured on the server to allow it. Thus, a completely fixed header name/value pair of IsCsrf: no is sufficient to prevent CSRF, so long as no third-party sites are allowed (per CORS preflight responses) to send requests with that header set. No randomness required.
Anyhow, that approach certainly doesn't require the server to pick a string, except in the sense of "the server should probably have a known header name it looks for". Nothing else matters, and it's fine for every user to use the same string (so long as there's no way for one user to force another to make a forged request from the target site directly... but of course that's not Cross-Site Request Forgery anymore).
Of course, that approach means all state-changing requests must be sent using script, which is undesirable for some sites (and already inherent for some others). Doing the more traditional version of double-submit cookie - where the value is both in a cookie and in the request body - is much more broadly compatible, but suffers from the thing where the security model of cookies is kind of a mess (what happens if the same cookie name is set with different values in Secure and non-Secure contexts? Why is it possible at all for a value set in a secure context to ever be visible in an insecure one, or vice versa?). There are various approaches to solving this - the most portable and widely-supported being HTTP Strict Transport Security (HSTS) as this effectively makes all cookies "Secure" whether they are actually flagged that way or not and totally obviates the issue of non-secure contexts - but if you're going for modern solutions you can also just use the SameSite flag and just break the assumption that cookie-based sessions mean CSRF risk.
If you go with traditional double-submit cookies, I don't see any reason they need to be generated server-side. The important part is that something a cross-site request controls (the anti-CSRF token in the body) and something the cross-site request (hopefully) doesn't control (the anti-CSRF token in the cookie) match, or at least have some tightly coupled relationship (it's fine for one to be a cryptographic hash digest of the other, for example). On the other hand, double-submit cookies are... not a great approach, because there are too many ways to plant a cookie on a victim that suddenly you need to be careful about.

Or you can go with your initial idea, of hashing the session token and using that value as the anti-CSRF token! This is actually a great idea, one I wish I saw more often. It's as stateless as your session token. It's as secure as your session token (which had better be "very"). It inherently solves a problem I've seen in home-rolled anti-CSRF code, where the CSRF tokens are generated and checked securely but nobody remembered to tie them to a session, so I can log in, see my CSRF token, and use it to CSRF you even though you're supposed to have a different one. The meaningful requirement of anti-CSRF tokens isn't actually that they be "random", it's that they be "unpredictable", which is less strict. Since the exact same constraint applies to session tokens (e.g. a JWT is not at all random, but it does contain a very unpredictable signature), it's perfectly reasonable to use the session token as a source for the anti-CSRF token. Leaving the session token as HttpOnly and hashing it to get the anti-CSRF token means no risk of somebody stealing the session token through XSS (though of course, remote-controlling the site using script injected via XSS will still work; stealing the session token itself is less relevant than some people think).
If you're still concerned about randomness, you can easily solve this by using a (random) salt and concatenating the (unhashed, plain-text) salt with the hash digest rather than using the digest alone... but I'd love to hear any argument for any attack this actually protects against.
Obviously, if you use the "hash of the session token" approach and your session token is still HttpOnly, you do need to generate the anti-CSRF token server-side. Fortunately, that's really simple to do. The server won't even need to re-compute it except when actually checking the value; the value could be computed once and stored client-side (in local / session storage), then get dynamically injected into any HTML form or similar request where the protection is needed.


I'm not 100% sure what point your lecturer is trying to get at, particularly because "DEP" is a vague term from a historical perspective.

I know that you asked us not to provide technical details, but I think they're warranted here from a history perpective.

There are two types of DEP:

Software-enforced DEP, which is actually SafeSEH (nothing to do with preventing execution of non-executable memory pages)
Hardware-enforced DEP, which allows the OS to mark memory pages as non-executable in such a way that the CPU will refuse to execute code in them.

You might be wondering "why the heck did they call both of these DEP?", and the answer is essentially that back in the early 2000s SEH pointer overwrites were the primary trick used to exploit stack buffer overflows, so "software data execution prevention" was a reasonable name for an exploit mitigation that prevented an attacker from redirecting EIP using overwritten stack data. We now call this SafeSEH instead.

The second half of the equation in such stack buffer exploits was to redirect EIP to a buffer that the attacker controlled (in this case the stack) which is where hardware-enforced DEP comes in. By utilising the NX feature (Intel calls it XD, but NX caught on as the common term) of the CPU, the OS can mark pages as non-executable and if an attacker tries to point EIP to some memory inside that page the CPU will refuse to fetch instructions from it and raise a hardware exception. As part of enabling DEP, the OS sets the stack up to be non-executable memory when creating the process. As this was the second part of preventing exploitation via stack buffer overflows, and it was enabled by the hardware NX bit (also called the XD bit) it got the name "hardware DEP".

(intermission) If you're curious about SafeSEH, it works by maintaining a list of valid exception handlers at compile time and the exception dispatcher won't transfer execution to a location not on that list. There's also SEHOP, which walks the full exception chain before dispatching to ensure that it is intact and complete (there's a special SEHOP record injected onto the end of the chain so it can find the end) - this prevents an exploit from overwriting a handler entry. The bonus of SEHOP is that you don't have to recompile the application with SafeSEH support.

From now on I'm just going to use the modern terms (DEP and SafeSEH) because otherwise this gets confusing.

The way the DEP policy works on Windows is as follows. There are four system-wide policy options: off, opt-in, opt-out, and forced. Portable Executable files (e.g. EXEs and DLLs) can set the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag in the DllCharacteristics field of the PE Optional header to indicate that they are NX-compatible (i.e. they know about NX and won't try to execute non-executable pages). The combinations are as follows:

When the DEP policy is set to AlwaysOff, the NX_COMPAT flag is ignored and DEP is not enabled for any process.
When the DEP policy is set to OptIn, the OS honours the NX_COMPAT flag; processes without it don't get DEP, processes with it do get DEP. However, the administrator may set up Image Execution Options for particular applications to force DEP to be on for them regardless of the value set in the PE header. Additionally, the process can call the SetProcessMitigationPolicy API with ProcessDEPPolicy to enable DEP on itself (although this is unlikely, as processes that are DEP-capable would likely just set the PE flag). This API can also be used to permanently enable DEP for the process (i.e. a later call to the API telling it to disable DEP would be denied).
When the DEP policy is set to OptOut, DEP is enabled for all processes by default, regardless of the NX_COMPAT flag. Like with the OptIn policy, the administrator can configure Image Execution Options for particular applications to disable DEP. Again the SetProcessMitigationPolicy can be called by the process with ProcessDEPPolicy to turn DEP on or off, or permanently enable it.
When the DEP policy is set to AlwaysOn, the NX_COMPAT flag and Image Execution Options are ignored and DEP is enabled for every process. The SetProcessMitigationPolicy API cannot be used to disable DEP when this policy is set; it is permanently enabled for all processes.

With all this in mind, there are a few things I think your lecturer might be trying to say:

Originally when NX came out, OS devs thought about setting everything to non-executable and making applications mark things as executable, but this would lead to problems with applications that incorrectly assumed that non-executable pages could be executed. This would mostly affect packed/compressed applications and anything with a JIT engine. So, instead, OS devs decided to default to letting processes just execute any data they like unless they opted into DEP, for compatibility reasons. In this case "X" is the original thinking, and "NX" is the approach they ended up taking.
SafeSEH (previously known as "software DEP") requires applications to be recompiled with the feature enabled, whereas SEHOP can just work on application that aren't compiled with SafeSEH. In this case SafeSEH is "X" and SEHOP is "NX".
Originally we were just going to have a policy of having applications be DEP by default but this doesn't work in practice, so we built a load of policy options (OptIn, OptOut, AlwaysOn, AlwaysOff). In this case "X" is the original on/off approach, and "NX" is the policy approach.

Sorry that I couldn't give you a simple straight answer, but hopefully this has somewhat improved your understanding of how the terminology evolved and how the current NX/XD/DEP/SafeSEH/SEHOP policies and ecosystem came together.


Can the GlobalProtect VPN of my company track websites when Disabled?

When you say "disabled" I will assume you mean "disconnected" from the VPN. I will also assume this is a company asset and not a personal asset.

You can't be completely sure based on the information you gave, but I would say generally no based on the research I've done and based on my manual poking around our Palo Alto admin console (and local log examination). They can (and hopefully will) monitor your traffic while you are connected to the corporate network, whether you are on-premises or connected via VPN. Also, here is a list of PA GlobalProtect features you can reference to get an idea of what is seen/logged. If you disconnect or disable your VPN and visit your bank, when you reconnect, this shouldn't be available in the Palo Alto logs.

However -- here are a few other things to consider:

You may be violating the company Acceptable Use Policy (AUP) whether or not you are connected via VPN. Don't violate the AUP.
There are many other ways security and infrastructure teams monitor user activity. A good example would be an endpoint agent that logs your activity and then pushes it to the syslog servers once it's connected.


If you are said ISP or government, then yes it is possible. GCHQ surely has the capabilities to intercept huge chunks of Internet traffic. They are most likely able to do some amount of MITM but it's not been disclosed whether they do that or not as part of any program.

I would also assume that a competent adversary could break into an ISP and target a specific client of that ISP, though I've not heard of such attacks in years.


Can motion sensors be disabled by lasers without triggering the alarm?

I wrote the security technical advisor to the movie Sneakers, Mr John Strauchs. Sneakers includes a scene where intruders increase the ambient temperature of the room in order to defeat the IR motion sensors. John wrote the technical details of that scene (including the purposeful errors).

John is a former operations officer at the CIA, and designs security systems for major locations around the world. This is a synopsis of what he had to say.

There are a couple factors to consider in your IR laser scenario.

First, is the complexity of the sensor itself. Top-of-the-line sensor units are a cluster of multiple sensors (up to 16) that create different zones to monitor. If you want to blind this type of unit, you would need to blind all 16 sensors. Cheap sensor units have only one sensor, and manufacturers break up the field into zones using physical means. One need only blind the one sensor in a cheap model.

Second, is the nature of the IR laser itself. It would have to mimic the IR signature of the thermal energy in the sensor zone it was in when you first turned it on. The IR signature would have to match everything between the sensor and the barrier in that zone. You could obtain this with an IR camera and some fancy math to program the laser, but it would be tricky, if not impossible, assuming you could get the IR laser to even produce a signature something close to the thermal equivalent to room temperature. To have this level of control this would require a near-weaponized level of complexity in an IR laser. In short, using a laser would be the easiest way to trip the sensor, not blind it.

John says that this is unnecessary, though, if you have close physical access to the sensor when it was off. A simple silicone spray will blind the sensor, and is invisible to the naked eye. It leaves a trace, but it might not be discovered until much later, if at all. Alternatively, you could place glass in front of the sensor when it was off, which would do the same thing. Glass and silicone sprays block the IR wavelength bodies emit.

That last piece of advice is the kicker for defenders. PIR sensors need to be inspected regularly, and even opened to see if glass or plastic was inserted inside the unit. Sometimes contractors will "tune" the unit by putting plastic inside to make the unit less sensitive. Always test PIR units by doing boundary tests, not by waving your hand right in front of it.

TL;DR:

It depends on the sensor manufacturer, and you would need a weaponized IR laser to even attempt this. Inspect your PIRs frequently for glass, plastic, and coatings, and test frequently using boundary tests, not waving your arms in front of it. You get what you pay for in sensor units.


Video Tutorials resources for IT Security

SANS security institute has many many videos on you tube


The worst case scenario you have to protect against is an attacker which completely compromises your server and obtains your sourcecode, your config and a dump of your database. Keep that in mind.

This is the scenario in which a salt is supposed to protect your passwords. Remote brute-forcing is not impaired by a salt at all (which is pointless anyway on everything but the most trivial passwords due to limited network bandwidth).

A few problems:

A "salt" which is the same for all passwords is called a pepper and doesn't increase security much when the attacker knows it.
SHA512 is a message digest algorithm, not an algorithm for hashing passwords. The problem with SHA512 is that it is too fast, allowing the attacker to brute-force the stolen password database very quickly. What you want is an intentionally slow algorithm like bcrypt. PHP has a very easy to use default implementation which can automatically generate, store and apply the salt for you.
Long, unique and impossible to guess session IDs are necessary, because when an attacker can guess the session ID of a logged in user they can hijack their session. PHP's session handling system assumes that any request which includes the session ID of a previously authenticated user comes from that authenticated user. In general you should rely on the session IDs which are auto-generated by PHP and only replace them with your own when you are sure you know what you are doing.
Minor point: "After that I connect to the database, escape all the strings and read out the data." Escaping all user inputs with mysqli_real_escape_string would be sufficient in theory, but in practice it is easy to forget about some rare edge-case where user-supplied strings end up in database queries. A better practice is to do all database queries with prepared statements which use the ? placeholder and bind for all variables. In that case the mysqli API does the escaping for you which is far more reliable, especially because it is aware of the context in which the escaped strings will be used. As an additional benefit it also has some performance and readability advantages.


What needs to be focused on when hardening a LAMP stack?

Any external service is a security risk. You indicated you're running a LAMP stack, so I'm assuming you have at least the following services running:

 1. SSHd
 2. Apache/Nginx
 3. PHP
 4. MySQL

MySQL by default is not externally facing, and you should not make it so unless you're involved in a clustering or replication environment (in which case there are alternatives to putting it on the wide web, like a VPN.)

Apache/Nginx + PHP cannot be made internally facing if you intend on providing content to people on the web, so these are going to be your main points of ingress.

SSHd itself has to be public facing (not always, but for the sake of simplicity in this case). Use of a Key pair for authentication and completely disabling password authentication is your best best for preventing people from obtaining access via this service.

Let's talk about webservices. Apache, Nginx, and PHP. These are the services that people will attempt to exploit in order to obtain access to your machine, so let's talk about securing them.

Firstly, you're going to want to isolate the services. If you've installed them yourself that means that ensuring that Apache and Nginx are running as non-root users.

Secondly, you're going to want to take a look at php-fpm or suphp, which allow PHP to operate as a user that is separate from your webserver even at a virtualhost or directory level.

This accomplishes two things, by taking root permissions away from Apache/Nginx, if someone gains control of that service they cannot impact anything but the operation of that specific service.

Changing the user of php (especially on a per-site basis) isolates the PHP module from interacting with other sites on the machine, and with the webserver itself, so if you have a client or website with exploitable code on it, your entire service, other sites, and your machine is not at risk.


How to enable WiFi while using two wireless cards one in monitor mode and other in managed mode?

You could do it all more "manually" :

Set your wlan0 interface down :
ip link set wlan0 down.

Change the mode from managed to monitor :
iw dev wlan0 set type monitor.

And bring back up :
ip link set wlan0 up.

And you can check the result with a simple iw dev.

That shouldn't change anything on your other interface wlan1, at least it does it for me (Debian 8). I don't know why you lose connection when launching airmon-ng start but I never managed to use it correctly, hence these 3 commands above...


What network topology should be used in a SOHO environment with a publicly available web server?

There's two aspects you should consider:

The web server will be accessible from internet. That's a pretty big attack surface compared to all the other internal hosts.
Your internal network might be as dangerous as the internet, the web server should treat it as hostile as well.

You can address both aspects with a simple setup like this:

                   .--.
               _ -(    )- _
          .--,(            ),--.
      _.-(                       )-._
     (           INTERNET            )
      '-._(                     )_.-'
        |  '__,(            ),__'
        |       - ._(__)_. -
                     \           \
        |             \
                       \           \
        |               \
        |           _____\____       \
  Only port 80     [_.Router.°]
        |           /        \         \
        |          /          \        No incoming traffic
                  /            \         \
        |        /              \
        |       /                \         \
        v      /                  \         v
     .Public network----.         .Private network.
     |  ________        |         |  ____   __    |
     | |==|=====|       |         | |    | |==|   |
     | |  |     |       |         | |____| |  |   |
     | |  |     |       |         | /::::/ |__|   |
     | |  |     |       |         |               |
     | |  |     |       |<- - - - |               |
     | |  |====°|       |         '---------------'
     | |__|_____|       |  Pt 80 only
     '------------------'

The dotted lines represent logical connections and the full lines are physical connections.

You just setup a separate subnet for the webserver and only allow access to it on port 80 (and perhaps 443).

You should be aware that this makes your router a single point of failure. In a SOHO environment this is usually the case anyway, but it doesn't necessarily have to.

Once this gets beyond the "just to see how it goes" phase you may want to consider hosting it on AWS or other cloud provider. You get the same level of control, much better redundancy, amazing scalability and great security for pennies.


The question in the original title of your post ("Can a website still detect my real MAC address even if I use different virtual machine each time I visit the website?") is different than the question in the body of your post.

To the question in the original title:  No, a website should never be able to "detect" your MAC address, under any circumstances.  The MAC address only identifies your NIC on the local network segment, it isn't passed upstream to a website that you're accessing via intermediate routers.

To the question in the post body:  The website many be able to uniquely identify you, and it may not.  There are certainly ways to try and fingerprint a repeat user (cookies, flash cookies, browser profiling, IP address logging, etc.)  that allow for various levels of confidence.  As Rory mentioned, using the same base VM potentially leaves you vulnerable to browser fingerprinting, but eliminates the threat from cookies.

However, To be relatively confident in your privacy, I don't know that I'd bother with the "new VM every visit" and focus on more traditional privacy-protecting measures such as turning off your browser plugins, using your chosen browser's private browsing mode, and most importantly, using Tor.


From what I know about PGP, it's built on the concept of Web Of Trust, where trust is transitive. PGP belongs to public key infrastructure, and its main purpose is to provide ground for the authentication of public key, i.e. some public key truly belongs to a person who the key claim to belong. Authentication here is implemented by me using my private key to sign someone's public key, in order to authenticate they are the true owner of the public key. Since people who know me, and my public key in person, can verify my signing using my public key, then they would automatically 'trust' someone's public key which I signed. This poses a security issue when I mistakenly believe the key belongs to someone and I sign it. Then, my web-of-trust would automatically trust that malicious guy.
Since people in the web of trust usually know each other in person, which makes it very difficult to engage in, thus preserving some degree of privacy within the group.

So, coming back to your question, it all depends if such degree of privacy is needed, a group-level privacy, when deciding whether or not to use PGP.


The scenario you describe is very similar to the concept of "remote attestation". There has been a lot of research on this and there are two major results:

You need a trust anchor, such as the TPM or a trusted system service, to securely measure your app and report the results to the server. Otherwise you can always build a simulator that generates the correct responses[1].
Once you deploy and use all the trusted computing infrastructure, you still can't prevent or even detect exploitation of vulnerabilities in your app with any more assurance than by deploying today's standard anti-buffer overflow technology.

So, if you want to deploy this today, your best option is code obfuscation. Basically, you want to implement a copy protection mechanism, same as it has been implemented and broken for decades.

[1] There have been some very cool advancements that exploit computation and communication limits of the client platform, but this is still sci-fi.


How do I brute-force a password when I know the format?

You can generate a list of passwords matching the format you want using hashcat:
hashcat --stdout -a 3 ?u?d?d?d?d?dhd

will generate Udddddhd where U is upper, d is digit, but the last 'hd' is just 'hd'.  More information about hashcat mask mode is here.
Once you've generated your wordlist, you can use a tool like Hydra or Hatch to feed those passwords into the web form.


Is using HTTP for OCSP a potential vulnerability?

The CRL's and also the OCSP responses are signed by the CA. This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport. Thus the protection against tampering which is offered by https is not needed.


Can I test ssl connection locally with a valid certificate (CA) with local dns?

For validating the certificate it is relevant that the domain in the URL matches the certificate. The certificate itself can be provided from any IP address, i.e. it does not have to be the public visible IP address but can also be a local one like 127.0.0.1. The mapping of domain to IP address is usually done by DNS but can also be done with a local hosts file, i.e. /etc/hosts in Linux.


What is a collision attack in simple terms?

Collision attacks aren't an issue when dealing with password hashes.   The issue with both SHA256 and MD5, from a password hashing perspective is that they're both much too fast.  MD5 is quite a bit faster than SHA256, in fact.

To clarify what a collision attack is, and why it doesn't matter when dealing with password hashes, it is when a hash function allows an attacker to find two inputs that result in the same hash value.  The fact that the attacker can control and manipulate both inputs in order to find a colliding value is critical.  When you have a password hashing system, however, the attacker does not have to ability to control the first input.  The password creator controls the first input.  The attacker only has the resulting hash value from the first input, and the ability to attempt to create a matching hash from a second input which they do control.  If they can find a second input that creates an identical hash, this is not a collision attack, but a 2nd pre-image attack, and not even MD5 is susceptible to these.

So, ultimately, the speed is the only issue, in that people choose passwords poorly, and the speed with with an MD5 hash can be computed is rapid enough for an attacker to attempt many, many potential input candidates in order to find the one the results in the password hash.


PGP public key block Public-Key (old) - What does the OLD mean?

OLD likely means your PGP public key block uses old packet format. See: https://tools.ietf.org/html/rfc4880#section-4.2


What factors should I consider when choosing the key for encryption and decryption?

Can I use the employee's password itself as the key?

No. They won't be able to change their password without reencrypting all data and a password is usually a weak encryption key.

First derive a secure hash from the password (e.g. using PBKDF2, Argon2 or a similar Key derivation function), then generate a secure encryption key from a good random source. Use this key to encrypt the data and encrypt this key with the KDF-Hash of the user password. When the user changes the password, you just need to reencrypt the encryption key, but not all the data.


Optimal flags to specify when using nmap to guess the OS on remote devices?

Understanding how Nmap does OS fingerprinting will help you considerably. For the quick answer, though, here are the relevant points:

Nmap needs responses from 1 closed and 1 open TCP port to do a fingerprint.
Nmap can also use ICMP and UDP responses to further refine the match.

So you can see that you are wasting valuable time scanning for SCTP ports (-sY and -sZ) which are not used in OS fingerprinting. You wisely limit the port scanning phase to the 100-most-common ports with -F, but you may be able to reduce that even farther if you are not on a heavily-firewalled network.

Here's an example command that ought to be a good balance of speed and accuracy:

nmap -v -sSU -pT:20-25,80,443-445,U:54321-54330 -O $TARGET

EDIT: Nmap uses ICMP responses to probes to closed UDP ports in OS detection, so scanning likely-closed UDP ports will actually be better than what I said previously (-p U:53,111-161). Responses from open UDP ports are not used.


Is someone trying to break in my WIFI router?

Yes, as posted in the comments, this looks like an evil twin attack. Someone is likely trying to obtain your network's PSK by:

Creating an open network with your ESSID
Kicking you off your real network with a deauthentication attack
You manually connect to the attacker's network because yours isn't working
You type your PSK into a captive portal on the attacker's wireless network

There is no other logical reason a duplicate network should appear, nor would a configuration page ask for a WPA PSK in that fashion.

While you can't prevent someone from creating their own access point, there are ways to mitigate damage.

The simplest solution is to not connect to the other network, and tell your household/users/guests to pick the network that is secured with WPA2.
A more advanced solution, as deployed in businesses and hotels, is a wireless intrusion prevention system (WIPS), which can actively deauthenticate clients that attempt to connect to unauthorized wireless networks. The legality of such active measures may vary by jurisdiction.
Find out who is performing the attack and get them to stop or involve law enforcement.


Is there a particular security weakness from using server-side JavaScript?

JavaScript is a language just like any other language, such as C and Java. You can run Java on your desktop PC, and on your server as well. In the same vein, you can run JavaScript just fine on a server.

Node.js is one popular asynchronous I/O library that uses the JavaScript language. It runs extremely well in a server environment as evidenced by GitHub and Klout.

The same origin policy is only applicable in browsers, i.e. at the client side. The sandbox is still in the language in the sense that you probably will not hit a buffer overflow. It is not the same sandbox as implemented in browsers, that is, no access to sockets, and no access to files.

The bottomline is to think about JavaScript as a generic language.

The drawback from a programming point of view is the JavaScript interpreter runs single-threadedly. There could have been improvements in this area. From a security point of view there are likely no issues to worry about.


Yes, mutual authentication using a client certificate is ideal here. IP filtering is a good control, but it should only really be used as a secondary security control.

As an example of how the IP filtering could fail here, assume that the client (it's a server but in this case it's the one initiating the TLS connection) is on a network that can route out to the internet in order to talk to the server. Now imagine that instead of attacking that client box, an attacker finds a way into a completely unrelated system on the same network, or even the router itself for that subnet. They can now talk to the remote server because they're routing out as the same external IP address.

With mutual authentication the client certificate is on the client system only, so the attacker cannot communicate with the remote server even if they break into the same network as the client.


How to use DPAPI under load balance environment

There are two relatively small changes you should make to your setup.

First of all, you should always be using DPAPI in USER_MODE, this is a parameter to the DPAPI methods.
(The .Protect() methods of ProtectedData and ProtectedMemory classes take an additional scope parameter, this should be set to DataProtectionScope.CurrentUser for ProtectedData, or MemoryProtectionScope.SameLogon for ProtectedMemory, depending on which you are using.)
(If you are calling the WINAPI functions directly, which I hope you're not using, you can send the USER_MODE parameter directly too. Oh, and use the .NET classes instead.)

Secondly, you should be using the DPAPI classes to encrypt your encryption key - not the data directly.
In other words, you generate a single encryption key, distribute this to all your servers, and have them store the key via DPAPI. (Yes, you'll probably need a small utility for this.)
This will make any key management processes much easier, the key is shared so decryption is easier, and it is still protected by the DPAPI encryption.


First of all, you can look beyond just dictionary and bruteforce. There are many other approaches possible (dictionary + rules, masks, combinator attacks, hybrid attacks, etc.). The hashcat wiki and/or the John the Ripper (jumbo) MODES doc list a number of the other possible attack types.
You didn't mention what your current capability (hashes per second) is, but I'm assuming that it's either CPU-based, or using a single GPU. If it's CPU, you should try GPU (OpenCL/CUDA), which is dramatically better for some kinds of attacks. If you're already using GPU, then depending on your budget, the most cost-effective method in the time allotted would probably be to rent a GPU compute instance - Amazon, vast.ai, Google Cloud, etc. - using NVIDIA GPUs, and either hashcat or John the Ripper.
You also didn't mention which dictionaries you tried - that matters. The best wordlists are user passwords from other sources, such as the hashes.org founds lists. Using these as wordlists, and then adding rules to "mangle" them in various ways, can be very productive.
In other words, you have many additional options. If you ramp up quickly, you could cover a lot of ground in that week.
Note, however, that while these overall strategies are good at improving your cracking success rates on average ... they're no guarantee that you'll get any specific password. But if you're cracking thousands of passwords, adding these techniques will usually significantly increase your percentage of successful cracks.


any information about en.quiente.info who has visited your account website

The site works (most likely- I haven't visited it either) by requesting YOUR permissions to see and record what YOU do. It then looks in its database to see if your friends also use it- if they do, it can show you what THEY have done.

It can't show you what anyone who is not a member of their site is doing, which is why it is so insistent that you get your pals to join.

It should unsurprising to anyone that using it is a terrible idea, and will turn predatory if not malicious at some point, as others have mentioned.


This looks like a sloppy design to me, that degrades performance by storing more tokens than necessary. But I don't see a security issue.

Why? To bypass the CSRF-filter the attacker would need to know the value of a token. But there is no leaking of that info in your example, just multiple tokens. Only difference is that an attacker has two in a billion instead of one in a billion chance of guessing it right.

One thing to investigate further, though: The CSRF token should be tied to the session. That it still works after login makes me suspicious. Does any CSRF token work with any session ID? Then you have no CSRF protection at all. Or doesn't the session ID change when you login? Then you have a session hijacking problem.


Can I create an application that can decrypt data but the administrator of the application cannot?

This is possible to an extent, on Windows, using the Windows Data Protection API; more specifically the CryptProtectData function. This function allows you to encrypt data against a user profile or machine, so that only that entity may recover the data.

Your setup would look something like this:

A dedicated service user is configured for the application.
A helper application running as that service user encrypts credentials with CryptProtectData, with dwFlags set to 0, and stores it on disk or in the registry.
Application runs as the service user and decrypts credentials on startup, using CryptUnprotectData.
Create a group for application service users which is not also privileged in other ways (e.g. part of the Administrators group)
Use this technique to allow that group's users to start/stop the service.
Ensure that the group cannot write/modify the executable file, or any of the DLLs within the application directory, or otherwise cause an arbitrary executable to be run under the context of the application service user. This also means that they should not be able to modify the registry keys and values for the service under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

It is important to note that, should the application administrators be able to modify the application binary, or run a program under the context of the application service user, they could simply call CryptUnprotectData and gain access to the credentials.

If you make these application administrators part of the full administrators group, you are giving them the keys to the kingdom - they can install and run whatever software they like at this point (including kernel-mode code) and will be able to bypass any control you implement. Don't do that if you want to maintain control.


How secure is a Windows password protected zip file?

When creating a password-protected Zip file (with the "compressed folder" utility integrated in the OS), Windows XP uses the "standard" encryption algorithm for Zip files. This is a homemade stream cipher, and it is weak. With 13 bytes of known plaintext, the complexity of the attack is about 238 operations, which is doable in a few hours on a PC. 13 bytes are relatively easy to obtain (e.g. if one of the files in the archive is an image, it will probably be uncompressed and begin with a known header). The result has even been improved, notably because the files in an archive are encrypted separately but without proper key diversification. Some years ago (quite a few now, tempus fugit), I have seen a password cracking software by Ivan Golubev which put this science to good use, and could crack Zip encryption in an hour.

The attack on Zip encryption is actually:

a nice introduction to cryptanalysis;
a good exercise in programming;
a reminder that you should not roll your own crypto. Phil Katz was very good in his domain, but the best cryptographers in the world will tell you that it takes much more than one extremely good cryptographer to make a secure algorithm -- it takes many cryptographers who feverishly propose designs and try to break the designs of the others, for a few years, until a seemingly robust design emerges (where "robust" means "none could find the slightest argument to support the idea that they may, possibly, make a dent in it at some unspecified date").

Now, if you use a tool which supports the newer, AES-based encryption, things will look better, provided that the format and implementation were not botched, and the password has sufficient entropy. However, such Zip files will not be opened by the stock WinXP explorer.

If an external tool is required, you might as well rely on a tool which has been thoroughly analyzed for security, both in the format specification and the implementation; in other words, as @D.W. suggests: GnuPG.

As for self-decrypting archives, they are all wrong, since they rely on the user doing exactly what should never be done, i.e. launching an executable which he received by email. If he does open a self-decrypting archive you send him, then he will just, by this action, demonstrate that he is vulnerable to the myriad of virus/worms/whatevers which roam the wild Internet, and he is probably already infected with various malware, including keyloggers.

Nevertheless, there is a way, in your specific situation, to make a self-decrypting archive reasonable. It still needs your client to install a new piece of software, but at least it is straight from Microsoft: the File Checksum Integrity Verifier -- a pompous name for a tool which computes file hashes. Send the self-decrypting archive to your client, and have him save it as a file (without executing it, of course). Then, have him run FCIV on it, to get the SHA-1 hash of the file. Do the same on your side. Finally, compare the two hashes by phone (it is not hard to dictate 40 hexadecimal characters). If the two hashes match, then your client will know that the file was not modified during the transfer, and he will be able to execute it with confidence.

(That is, if your client trusts you, and trusts that your machine is not clock full with virus which could have infected the archive on its way out.)


How should I choose a difficulty factor for my password hashing function?

Unfortunately, the wide variety of hardware prevents building tables like the one you want unless you first make a survey of all existing hardware architectures and the best bcrypt/scrypt/PBKDF2 implementations for that architecture. Even the table in the scrypt article is not what you want: it does not tell you how much it would cost for an attacker; it tells how how much it would cost for an attacker with the hardware and software the scrypt designer thought of when writing the article.

Such estimates do not scale up well, by the way. If I was an attacker faced with an attack cost estimated at 10 billions of dollars with available hardware, I would first invest one billion dollars into building a custom ASIC-based system which would be faster for that job. A PC is good at making pseudorandom RAM accesses, but not the best possible hardware for that, if only because there are a lot of other components in a PC, which are useless for an attack.

At least, for PBKDF2, since the computation maps to the underlying hash function with no memory access issues, you can use existing hash function benchmarks to get an idea (e.g. these ones).

That being said, all is not lost. You will not get accurate estimates of attack costs, but that does not mean that all you can do is wail, shrivel up and die. A first pragmatic method is to set up the iteration count as high as you can: set it to the highest value which does not make the normal login process intolerably slow. That way, you will not know if your security is good, but it will be as good as it can get. Which is a consolation.

The rest of the work will be on the users' side. After all, the difficulty factor in the password hashing is there to counteract Moore's law. However, at best, this is a match between the password entropy and the attacker's patience:

The attacker's advantage is that he is richer, can buy dedicated hardware, and is patient: he can afford to spend one hour, maybe one day on cracking a high-value password; whereas the user will not tolerate waiting for more than one second when logging in.
The defender's advantage is the password entropy.

Accounting for an efficiency factor of 1000 for the attacker (dedicated hardware, more dollars thrown at it) and a patience factor of 86400 (the attacker wants to succeed within a day, the user will not wait more than one second), then the password entropy must exceed 86 millions (aka a bit more than 26 bits) if the defender is to win the game. To raise the password entropy, there's only one way: educate, educate, and educate again. Don't try to enforce "password rules", they antagonize users rather instead of making strong passwords. Instead, provide a non mandatory password generator button, which produces passwords with, say, 40 bits of entropy, and explain to the users that using the button would be a very good idea.


Why is this XPATH injection attack failing, and what is going on in the background of attack?

Hope this will help:

First of all, if right queries don't show anything you're dealing with a blind XPath injection.

Second, the error you've talked about:

  Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.Xml.XPath.XPathException: Namespace Manager or XsltContext needed. This query has a prefix, variable, or user-defined function.

May require to add the namespace before the query.

This:

  //acctprofile[acctid='555-555-555]'test']

Should be more like this:

  //"namespace":acctprofile[acctid='555-555-555]'test']

But this requires for you to know the namespace or to have any variable to insert there.


Question about SSL certificate and third party server

The best practice is to trust the root CA, for very practical reasons.

Root CAs are a special beast and are expected to have very long lifetimes (20 years or more) because they require replacement in the client software, which is usually a manual process.

Intermediate and server certificates are expected to change frequently - in some cases (load balancing for example) they can change minute-by-minute.  You should not expect to receive any notification from the server operator when the certificate changes.

If you put the root CA in your trust store, you're saying "I trust this CA - any and every certificate signed by this CA is ok with me".  That's usually ok, since the point of the CA is to provide a trustworthy signature for unknown servers.

The only time you would want to use a server certificate is when you don't trust the CA - but that itself causes further problems, and perhaps TLS is not the right approach in this case.


This is a perfect example of how Security Groups and the Best Practices concept of Separation of Duties comes into play.

Create security groups for your users, by departmental or functional role - one of those security groups should be something like "Helpdesk-LocalAdmin" (choose something consistent with your own naming convention - if you don't have a standardized naming convention already, it's never too late to establish one).

Create a group policy, call it something like "HelpdeskLocalAdmin", and:

Expand "Computer configuration\Policies\Windows Settings\Security Settings\Restricted Groups"
In the right pane of "Restricted Groups", right click and hit "Add Group..."
Type the name of your Helpdesk Local Admins group, ie: Helpdesk-LocalAdmin and hit 'OK"
Click Add under "This group is a member of:"
Add the "Administrators" Group.
Click OK

Now, for each of your Helpdesk personnel who should be granted Local Administrator account access, add them to the "Helpdesk-LocalAdmin" security group, and the GPO will automatically be applied.

Explanation:
Every "privilege" in a networked / computing environment should be "default deny", meaning that users must be explicitly granted access to network / server / application resources. This allows you to very specifically control who has access to what, instead of attempting to later deny those who shouldn't have access and keep track of them.


They may be able to gather some details about your connection since I believe that Skype at least used to go direct from one user to the other when in a voice call, so they could potentially identify your IP address, however they would be limited to what Skype allows them to do or any bugs in Skype allow for.  If Skype is bug free, they shouldn't be able to do much of anything, but if someone found an exploit in Skype, then it could be anything.  It's probably not super likely that someone has an exploit for Skype that is being used in the wild a lot that hasn't been detected yet, but it's always a possibility.


SSH Access to Personal Server sudo vs su

Well If you are using sudo you can use the sudo file (only editable by those with permissions) to control what your user can do, for example you could turn your own user into a root with sudo -s or you could allow them to only use certain commands and even parameters you allow them to in the sudo file, so if I am understanding correctly (someone correct me if i am wrong)

The best choice is sudo and locking down / opening up certain rules for your user so it can perform certain tasks, you should only ever use root as a last resort for the saftey of your own system.

I forgot to add, having a password is the better way to go if you are constantly changing machines though this leaves you open to brute force attacks. unless obviously you use a fail2ban and often rotate passwords.

Using a key and a password is the best option but that means every device you use will need this key.


Friend borrowed gaming keyboard to use on severely virus infected pc. danger to keyboard?

In fact, this is possible and Logitech peripherals have been used to attack machines, or to move malware from one host to another. Time doesn't really matter, because an infected PC can flash a hardware device in seconds (probably less).

Though I think it is highly unlikely you have been infected, for two reasons:

This type of expolit has not been seen on mass scale (yet) and has primarily been a topic of studies.
In addition to that, the malware must have been on the PC in the first place, and should have been capable of infecting you keyboard without any firmware corruption. This requires skills and a highly sophisticated piece of malware.

From what I gather, I don not think you have anything to worry about.

Update:

Like you said, a keyboard firmware will likely whipe the ROM.


Correct terminology when describing password security to layman

"We believe the secrecy of your passwords is very important, which is why we have implemented measures that strongly protect them while stored on our servers.  Once you submit your password we convert it using a cryptographic function (salted PBKDF2-SHA256 with 64,000 iterations for the tech savvy), so even if attackers are able to breach our site they won't immediately learn your password.

This method of storing passwords makes it significantly harder for your password to be cracked by the bad guys.  Choosing a unique and good password/passphrase choice paired with this technology can help prevent unauthorized access to your account.  Even our employees won't know your original password."

Similar to Adam's suggestion, just expanded to cover more of your concerns.


Time of working generating hash with sha2

Yes, this is true, though the timing differences between two short messages (e.g. 100 and 1000 bytes) are negligible. Computing the SHA256 hash of a gigabyte of data understandably takes much longer than computing the SHA256 hash of a few hundred bytes.


Does Windows really still use unsalted MD4 for password storage?

NTLMv1 uses MD4, v2 uses MD5, and the Windows implementation of Kerberos uses a KDF using HMAC-SHA1 for AES 128/256.  Active Directory can actually store multiple types of hashes of passwords depending on what you are wanting it to do, and what versions of protocols are enabled.
Yes, Active Directory uses unsalted passwords. Is this a security problem? Theoretically yes, but practically probably not. The AD database was designed to be stored in a protected environment where only trusted people have access to the actual file, and only trusted systems can read the data in the file.  A salt really only adds value if the particular store containing the password is accessible by potentially non-trusted people and/or non-trusted systems like a SQL database that also contains content.  If you are letting anyone and everyone access the AD database you have bigger problems than password salts.
Then of course the other side of this goes to backwards-compatibility as well.  Microsoft has to make sure the current version of AD is backwards compatible with the one 4 versions prior.  Is this good for security? Not really, but they would be crucified if the versions weren't compatible.  Are they changing the hashes to something more secure? Yes, albeit slowly.


You are doing a conversion from hex encoding (or base16 if you like) to base64. So you are base64 encoding the ASCII characters 9 (57), B (66) and 2 (50) giving you OUIy.

What you should be doing is base64 encoding the raw bytes. So you should encode 0x9B (155) and 0x23 (35) giving you myM.


OS (or platform) agnostic metrics to understand if a system is compromised?

There is no simple set of metrics I'm afraid. Modern computers are designed to be general purpose and so are very complex.

Modern compromises may also be complex. Many Windows compromises are very hard to detect and certainly wouldn't touch the registry.

Some changes to look for across systems are:

Changes to the boot sector
Changes to system files that don't match controlled updates
Changes to configuration files that don't match controlled updates

From this, you can probably recognise that you need to have very tight change controls and methods to track changes.


Does x509 have an "issued at" timestamp? Can you tell when an x509 certificate was issued?

X.509 has a Not Before and a Not After field which describes when the certificate is valid to use for the defined purpose. The Not Before usually matches about the time when the certificate was issued but it is not required to do so.


While it is possible to store a hash of an email address similarly to how passwords are stored in a hashed form, the only case I can think of this being used is for accessing Gravatar images, and even then the the site itself does keep cleartext entries of email addresses in their databases.

Almost certainly, if somebody asks for your email address, they have stored it for later use of some kind.


Why is information obtained from public records considered a secure way of confirming your identity?

You ask how and why information about you is "secure enough" to serve as an authenticator.  The answer is, it's not.

Identifiers must be unique, and there must not ever be a need to change an identifier.

Authenticators need not be unique and must be changeable if the authenticator is compromised.  Further, authenticators must not be researchable.

So, example: the SSN is a dandy identifier; it's (supposed to be) unique and seldom if ever changed.  It's a terrible authenticator.  Literally thousands of people have legitimate access to your SSN and mine:  bank, employer, stockbroker, IRS, and others.

Similarly, you cannot (legitimately) change your birth date, mother's maiden name, bank that services your loan of 2005, your first car, and all those other things that people sometimes try to use as authenticators.  And they're all researchable.

That, relying on researchable authenticators, is how the IRS managed to give 100,000 tax returns to scammers earlier this year.


Decoding tunnel bytes in EAP-TLS or EAP-TTLS using Wireshark

If you have RSA keys and the transport uses a non-DHE ciphersuite, you should be able to decrypt EAP-TLS with Wireshark. There was however a bug that got fixed in the development version (v1.99.10rc0-191-g5e635ad) and will end up in the 2.0 release.

At the moment you have to specify dummy values for the port number and such, but after that you should be able to decrypt EAP-TLS traffic. Go to Edit, Preferences, Protocols SSL, RSA keys list. Then fill in the following details:

IP address: any
Port: 0
Protocol: data (anything would work here)
Key File: path to your key file
Password: empty for PEM-formatted key files, a password for PKCS#12 formats otherwise.


Weird URL showed when telnet to my server

is this normal [that the my server login reports a different domain]

Of course not.

  I am using ubuntu and it was compromised before

Well ... you shouldn't have continued using it.

  but I have scanned my server and delete all infected files

Virus scanners on an already compromised machine are pretty useless. (Even more useless than at other times).

  including changing my default SSH port (22) to another one

Does this matter?
Does this matter if you're using telnet?

And why you are using telnet!?

  I checked this IP 43.252.11.213 ... and redirected ...

You also should never have called this in a browser.

  is it meant that my site is copied to other domain?

No. Well, maybe, but that's not the problem. Until proven otherwise, assume that someone else has full control over your server (including all content, but also all other things the computer can do).

What you should do now:

Try to find out how your server got compromised and fix that (the probability is low that you find the reason). Also change all passwords, get used to regular software updates, SSH keys, fail2ban and so on.
Wipe your server clean and start again by installing an OS, all necessary software, and all configs you need/want.