Mythbusters: Is An Open (Unencrypted) WiFi More Dangerous Than A WPA2-PSK? Actually, It Is Not.

Introduction

Whenever security professionals recommend the 5 most important IT security practices to average users, one of the items is usually something like: "Avoid using open Wifi" or "Always use VPN while using open WiFi" or "Avoid sensitive websites (e.g. online banking) while using open WiFI", etc.

What I think about this? It is bullshit. But let's not jump to the conclusions. Let's analyze all risks and factors here.

During the following analysis, I made two assumptions. The first one is that we are comparing public WiFi hotspots with no encryption at all (referred to as Open), and we compare this to public WiFi hotspots with WPA2-PSK (and just hope WEP died years before). The other assumption is there are people who are security-aware, and those who just don't care. They just want to browse the web, access Facebook, write e-mails, etc.

The risks

Let's discuss the different threats people face using public hotspots, compared to home/work internet usage:

1. Where the website session data is not protected with SSL/TLS (and the cookie is not protected with secure flag), attackers on the same hotspot can obtain the session data and use it in session/login credentials stealing. Typical protocols affected:

• HTTP sites
• HTTPS sites but unsecured cookie
• FTP without encryption
• IMAP/SMTP/POP3 without SSL/TLS or STARTTLS

2. Attackers can inject extra data into the HTTP traffic, which can be used for exploits, or social engineer attacks (e.g. update Flash player with our malware) – see the Dark Hotel campaign

3. Attackers can use tools like SSLStrip to keep the user's traffic on clear text HTTP and steal password/session data/personal information

4. Attackers can monitor and track user activity

5. Attackers can directly attack the user's machine (e.g. SMB service)

WPA2-PSK security

So, why is a public WPA2-PSK WiFi safer than an open WiFi? Spoiler alert: it is not!

In a generic public WPA2-PSK scenario, all users share the same password. And guess what, the whole traffic can be decrypted with the following information: SSID + shared password + information from the 4-way handshake. https://wiki.wireshark.org/HowToDecrypt802.11

If you want to see it in action, here is a nice tutorial for you

http://www.lovemytool.com/blog/2010/05/wireshark-and-tshark-decrypt-sample-capture-file-by-joke-snelders.html

Decrypted WPA2-PSK traffic

Any user having access to the same WPA2-PSK network knows this information. So they can instantly decrypt your traffic. Or the attackers can just set up an access point with the same SSID, same password, and stronger signal. And now, the attacker can instantly launch active man-in-the-middle attacks. It is a common belief (even among ITSEC experts) that WPA2-PSK is not vulnerable to this attack. I am not sure why this vulnerability was left in the protocol, if you have the answer, let me know. Edit (2015-08-03): I think the key message here is that without server authentication (e.g. via PKI), it is not possible to solve this.

Let me link here one of my previous posts here with a great skiddie tool:

http://jumpespjump.blogspot.nl/2014/04/dsploit.html

To sum up, attackers on a WPA2-PSK network can:

• Decrypt all HTTP/FTP/IMAP/SMTP/POP3 passwords or other sensitive information
• Can launch active attacks like SSLStrip, or modify HTTP traffic to include exploit/social engineer attacks
• Can monitor/track user activity

The only difference between open and WPA2-PSK networks is that an open network can be hacked with an attacker of the skill level of 1 from 10, while the WPA2-PSK network needs and an attacker with a skill level of 1.5. That is the difference.

The real solutions

1. Website owners, service providers should deploy proper (trusted) SSL/TLS infrastructure, protect session cookies, etc. Whenever a user (or security professional) notices a problem with the quality of the service (e.g. missing SSL/TLS), the service provider has to be notified. If no change is made, it is recommended to drop the service provider and choose a more secure one. Users have to use HTTPS Everywhere plugin.

2. Protect the device against exploits by patching the software on it, use a secure browser (Chrome, IE11 + enhanced protection), disable unnecessary plugins (Java, Flash, Silverlight), or at least use it via click-to-play. Also, the use of exploit mitigations tools (EMET, HitmanPro Alert, Malwarebytes AntiExploit) and a good internet security suite is a good idea.

3. Website owners have to deploy HSTS, and optionally include their site in an HSTS preload list

4. Don't click blindly on fake downloads (like fake Flash Player updates)

5. The benefits of a VPN is usually overestimated. A VPN provider is just another provider, like the hotspot provider, or the ISP. They can do the same malicious stuff (traffic injecting, traffic monitoring, user tracking). Especially when people use free VPNs. And "Average Joe" will choose a free VPN. Also, VPN connections tend to be disconnected, and almost none of the VPN providers provide fail secure VPNs. Also, for the price of a good VPN service you can buy a good data plan and use 4G/3G instead of low-quality public hotspots. But besides this, on mobile OSes (Android, iOS, etc.) I strongly recommend the use of VPN, because it is not practically feasible to know for users which app is using SSL/TLS and which is not.

6. Use a location-aware firewall, and whenever the network is not trusted, set it to a Public.

7. In a small-business/home environment, buy a WiFi router with guest WiFi access possibility, where the different passwords can be set to guest networks than used for the other.

Asking the question "Are you using open WiFi?", or "Do you do online banking on open WiFi?" are the wrong questions. The good questions are:

• Do you trust the operator(s) of the network you are using?
• Are the clients separated?
• If clients are not separated, is it possible that there are people with malicious intent on the network?
• Are you security-aware, and are you following the rules previously mentioned? If you do follow these rules, those will protect you on whatever network you are.

And call me an idiot, but I do online banking, e-shopping, and all the other sensitive stuff while I'm using open WiFi. And whenever I order pizza from an HTTP website, attackers can learn my address. Which is already in the phone book, on Facebook, and in every photo metadata I took with my smartphone about my cat and uploaded to the Internet (http://iknowwhereyourcatlives.com/).

Most articles and research publications are full of FUD about what people can learn from others. Maybe they are just outdated, maybe they are not. But it is totally safe to use Gmail on an open WiFi, no one will be able to read my e-mails.

PS: I know "Average Joe" won't find my blog post, won't start to read it, won't understand half I wrote. But even if they do, they won't patch their browser plugins, pay for a VPN, or check the session cookie. So they are doomed to fail. That's life. Deal with it.

Read more

1. Wifi Hacking
2. Curso Hacker
3. Hacking Curso
4. Sean Ellis Hacking Growth
5. Hacking Etico Que Es
6. Hacker Seguridad Informática
7. Travel Hacking

Read more...

Masad Clipper And Stealer - Windows Spyware Exfiltrating Data Via Telegram (Samples)

Reference

2019-09-25 Juniper. Masad Stealer: Exfiltrating using Telegram 

"Masad Clipper and Stealer" steals browser information, computer files,  and automatically replaces cryptocurrency wallets from the clipboard with its own.

It is written using Autoit scripts and then compiled into a Windows executable.
It uses Telegram to exfiltrate stolen information.

Download

             Other malware

Download. Email me if you need the password (see in my profile)

Hashes

SHA256	SHA1	MD5
1acf5a461ee16336eb8bbf8d29982c7e26d5e11827c58ca01adac671a28b52ad	6001b34c17c122d201613fffd846b056614b66da	e03234c2259c474aeb69500423ddeed7
290a1b89517dec10bfd9938a0e86ae8c53b0c78ed7c60dc99e4f8e5837f4f24a	32800c10588053813f55bf8c87771311c5f7f38e	2df4c1cf093c8373a8f2f194e77b69a2
7937a1068f130a90b44781eea3351ba8a2776d0fede9699ba8b32f3198de045b	a2a67b06344e4f1cf85086f6b584316ec53d5e54	8368f1c4d8f0d908f5f4ff671df5f1da
87e44bca3cc360c64cc7449ec1dc26b7d1708441d471bf3d36cd330db3576294	2fe5483e6b82220eeeef12e531eb3347fea16ac1	1082ce517dd23eee335bedfc6bcd8205
cf97d52551a96dacb089ac41463d21cab2b004ba8c38ffc6cb5fb0958ddd34db	5b79a15cb61f5260f0b9d807faa160e6d49590e4	b5fdf9653eb1ffbdae8cb4f1f2d71747
79aa23c5a25c7cdbaba9c6c655c918dac3d9823ac62ebed9d7d3e94e1eaafc07	4a279a6b82fe801d3c8be9d16df2ef5623b17704	0029ab0fd56cd7e493b46a331ef18bd3
03d703f6d341be258ac3d95961ff0a67d4bf792f9e896530e193b091dca29c2e	a9740352af2c9cc926deba7dffc452f213f7f05f	a462aac76def5b53351b3b1ddb41124c
a368b6755e62e5c0ff79ea1e3bd146ee8a349af309b4acf0558a9c667e78293a	e16167ab646381c277c2ca84319ceb57bacb2c92	c4cdc7665adb1cda5897d4df4a560f88
ba933cefbe9a8034f0ba34e7d18481a7db7451c8ef4b6172fb0cad6db0513a51	00749407e97085af470c75ef004f2235d30af44f	c26a3f2317507a09d91014469b045384
3ba3c528d11d1df62a969a282e9e54534fb3845962672ad6d8bbc29cb6d062f5	b8100890c0f1894544b3f99168377ec46c38e911	4a0607b4488cd539b8b0b443abd121e3
b763054180cd4e24c0a78b49055ad36dbc849f1a096cddf2db8cee0b9338c21d	7bec99308ce4bf409417b642cd9432000a5c19d2	2dfb1d606e5539399aa1a536baafd2f8
d5ce4b04b7eec6530a4a9d40510177468fadc235253e5a74530a8c9d990f3c50	27fc204ffa42262b7570b6fccb435d4d38a3610f	c5d8b73da810646407c333fe52186281
965a5949d8f94e17ebcd4cb6d0a7c19f49facbfc1b1c74111e5ceb83550d6c8f	7698584b2e7c62061447a6a2583ed6957180c205	e7ebe4411664672359b393f530fc2fc1
44134b9d4b10d94f6381b446a1728b116d62e65c1a52db45235af12caf7e38c0	fd114077927d501606575ba9ab38ecfb3407d432	a4388980d7e3539d74a950dab23d00ac
848d76a227f4fe282b7ddfd82a6dfc4c25da2735a684462b42fe4e1c413d8e34	135cee7610890497183eb6251efef307ea013fe1	7bb23077b4f80df48b91b425eda05828
5ca0a957fe6c253827f344da4ba8692d77a4e21a1df4251594be2d27d87dd8ae	d231874332ca462fb462e4f68450d2c2c22d4bcd	dda77b3f3f74a2bdffd167917686e139
016fa511f6546ed439d2606c6db8821685a99f5a14ef3f710668b58dc89c6926	5c83749c62ee0131710bf26931cb1e463a8fbda3	b0c34df85677d8f752dc1e1a5eeba0c9
22be594fbfa878f631c0632f6c4d260b00918817ff66a1f9f15efe44c1a58460	856d635fca52631305f1fefc58eafa74496524b6	60ebf41953d5c6e212fc306cdb0c6519
f3571ec66288405dab43332ca03812617f85fb08832fbbe1f1d89901fe034b8a	819485e20d841195e2e8a7ae5b41ff709887bb21	6984d37863c08b9fdd969297d35d3538
04c949eca23103b1de05278b49f42c3ab6b06f4bf20aafa5f2faefaa84c16ecd	0487db2df1802dd4ee4ae3b62b5f08937dd5c77c	4366ee61cbd7e636aea8540836a60036
d6fc04acda8f33a6d35eb577c27754c2f2b4d6f4869576c7c4e11b2c5e9b0176	83ae89826114662dad8553d5eeed5217b57047f2	2bc964e294d7ab314c34e5934d91a5a9
18c0bd4dd98008383fc52045ad896449fa7f0037593bb730ed1ef88aa547006d	bcaa05b60a9d625852ac4f2d0d805ab164988155	35d9f08c39c4cf396427f3a345e5c09a
4c9d5469e9095813418260045c2b11e499e4eaa0ffb25293f90f580c464157df	4c6aacc0b893ed366f9f307326e59efa61e51534	50dddaf7e5bb24aabf66eecd0c8b79cf
0b5f1fbc05dc8baca492b748adeb01fb4904e02723b59211ecde222f7b12d91e	87f898e0d41c0f2c22d4e9278a942326877fc368	da780b72140535d4c2d391e76dc8181d
31ad5c4547ceae4d0550c8460524c16a6105afc056760e872c4966656256c9dc	37f485d3fa8f6cf13061cb1ea38ae0d5d2edfd95	134aefcf640c24a1ab5344a96150fb05
edb00a0e5ff70e899857549e3263c887a799416c8bbab43ab130ca1be9bbd78c	42c30dc551a3cb3bc935c0eae79b79f17942e439	c2722241f765d2ad4fb58edd76a4adea
96f852b81760a425befaa11ea37c0cdea2622630bf2a0c94bb95042211ab614d	5d9782064bc38d40c88f32c0410479cbd61caa40	f332cfcda8c0ef579ede59eff23caa1e
57fd171a5b1a88e9583b42439851a91a940eb31105ab29cb314846da2ed43b82	0bfec2059823b936d782bea7bc16abd9923dddb5	6fff82df7a565b4570d299486697310f
277018b2cc6226dca6c7678cac6718c8584f7231340ad8cd7c03477559fdf48b	261f916ce97ffc6817a4772705df68e6ccca8181	009dc7d8766a85d85bb6a26ee69b66fe
e968affb1fc7756deb0e29807a06681d09a0425990be76b31816795875469e3d	cf78484a999183324da9affdf2aaeff508d1dc47	3e1b8f6313447b8a4b49671ddeb8a4ee
4b1ccf6b823ee82e400ba25b1f532cd369d7e536475a470e2011b77ffeaf7bb3	bc988f7cd32d411f2a9888afc72c7a892e2a1def	55128a3da6f70129acdbf9dbe955cfe7
fc84d6636a34ad1a11dbaa1daec179e426bdcd9887b3d26dc06b202417c08f95	1df31bec02e35c9a4656bb3a3bdf631bb37605a8	55d77ab16377a8a314982f723fcc6fae
9ca15f15fbae58cb97b0d48a0248461e78e34e6d530338e3e5b91f209a166267	8505dfaad6d10b84c73544eb748d547cb5bad9bd	ebc12c530dab0a65c37ffd72612fa705
31f3a402c1662ed6adffbf2b1b65cf902d1df763698eb76d21e4e94b4c629714	18c972722d984ff6da2bc26a0aca4c7f209cc39c	05bbf6e72b5b24c0c81e0671bf17b1e7
8d9f124ddd69c257189f1e814bb9e3731c00926fc2371e6ebe2654f3950ca02e	553cd98c83e945ee3013aa40897baec0305b34a2	b4030025e039c54c2d3923057447494c
a0923d7645604faaa864a079adeb741a5d6e65507a2819b2fee4835d396077d9	f8e6995e28c789d8b24e982ac53d5d6ba453de73	b796f85c8a7de71407d6e3c4206edda3
a19b790ea12f785256510dde367d3313b5267536a58ca0c27dbdac7c693f57e1	a92f7393daf7ead9a44b12e35f850705798fc879	a6defec886d31f6375712466dd794a96
f030fb4e859ee6a97c50c973a73dced3640befe37f579cfd15367ce6a9bbede2	ad3a1e779f02539ccd07bff735e0823add9730b2	c259564a8fe72333604a5686e30f6242
f01db6d77ac21211992ceae4e66e1e03c1cb39d61e03645b9369f28252ca7693	14c6bf63ff4d32d8a0a42e81ea39304fb7ab13c8	80fe593ef5538fbf66b3b3e1cb7b9b8b
dfe3d0e95feaed685a784aed14d087b019ba2eb0274947a840d2bdbae4ae3674	2107d057478328df8f538102508de00b0c4b37c7	b5a85a0e7a2c4197c3794c8bb2eb5763
bf6083040ca51e83415f27c9412d9e3d700bd0841493b207bc96abf944ab0ca7	09a695ce6c35c029dd7577e29f403d7144698b41	7a2edceb31a9c0d05e5f13c6caee0576
b154151dc8ace5c57f109e6bb211a019db20c4f0127c4d13c7703f730bf49276	8c0cda049c85493df4e97db3db4ddc94075ba62c	b6a895ac5ba5b6472680d47410a238a5
6bf6b1bde63cee9b81902efd187fdd56ecee5853754ce0a19d5ab5c3b0242988	6e2d4f0bcc97ce130ae89647f648d3e96548a391	a29f9d176b913e7f693355700aaadbb9
0dcf547bd8f4074af97416d8b84ea64b2f3319064aa4bce64ad0c2e2d3957175	a996b925e9391a69140caf6e4adba928694ffe66	dd575413a40839f2807593aa21c71152
6cff1249cc45b61ce8d28d87f8edc6616447e38168e610bed142f0b9c46ea684	9baa823deb9075e8df77b891115c019244de09de	488bb5c0739485721182c01a82b01d14
5b5ebe019806885bbaafe37bc10ca09549e41c240b793fd29a70690a5d80b496	3d46711f9064b96ff2d0affdef1ecd82d120659d	b95e2d8a8509ac05f5445d18d32cc7cb
103d87098c9702cab7454b52869aeeb6a22919f29a7f19be7509255ce2d8c83e	e29a163488438c9ea9014ddf1a9b2d382cc5d7e6	baf2587fafaedbab4a78b9b7fd8b55f8
c73675005a09008bc91d6bc3b5ad59a630ab4670dca6ac0d926165a3ecfd8d92	d8ea2280cd06a5cc32b7d668e2b4b2e68f3a7e2a	98ecc6fbb2cb5649daf751fcbfb81bcb
ef623aadd50330342dc464a31b843b3d8b5767d62a62f5e515ac2b380b208fbe	620ff5a7aaf7f3fcf4abc9365e0e77b3ec4b434d	b14535c5835c9dfb3cbbc7f6fef6034c

Related articles

1. Defcon Hacking
2. Tipos De Hacker
3. Curso Completo De Hacking Ético
4. Defcon Hacking
5. Hacking Roblox

Read more...

PKCE: What Can(Not) Be Protected

This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.

At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation" attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.

In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.

OAuth Code Flow

In Figure 1, we briefly introduce how the OAuth flow works on mobile apps and show show the reason why we do need PKCE.
In our example the user has two apps installed on the mobile phone: an Honest App and an Evil App. We assume that the Evil App is able to register the same handler as the Honest App and thus intercept messages sent to the Honest App. If you are more interested in this issue, you can find more information here [1].

Figure 1: An example of the "authorization code interception" attack on mobile devices. 

Step 1: A user starts the Honest App and initiates the authentication via OpenID Connect or the authorization via OAuth. Consequentially, the Honest App generates an Auth Request containing the OpenID Connect/OAuth parameters: client_id, state, redirect_uri, scope, authorization_grant, nonce, …. 

Step 2: The Browser is called and the Auth Request is sent to the Authorization Server (usually Facebook, Google, …).

• The Honest App could use a Web View browser. However, the current specification clearly advice to use the operating system's default browser and avoid the usage of Web Views [2]. In addition, Google does not allow the usage of Web View browser since August 2016 [3].

Step 3: We asume that the user is authenticated and he authorizes the access to the requested resources. As a result, the Auth Response containing the code is sent back to the browser.

Step 4: Now, the browser calls the Honest App registered handler. However, the Evil App is registered on this handler too and receives the code.

Step 5: The Evil App sends the stolen code to the Authorization Server and receives the corresponding access_token in step 6. Now, the Evil App can access the authorized ressources.

• Optionally, in step 5 the App can authenticate on the Authorization Server via client_id, client_secret. Since, Apps are public clients they do not have any protection mechanisms regarding the storage of this information. Thus, an attacker can easy get this information and add it to the Evil App.

Proof Key for Code Exchange - PKCE (RFC 7636)

Now, let's see how PKCE does prevent the attack. The basic idea of PKCE is to bind the Auth Request in Step 1 to the code redemption in Step 5. In other words, only the app generated the Auth Request is able to redeem the generated code.

Figure 2: PKCE - RFC 7636 

Step 1: The Auth Request is generated as previosly described. Additionally, two parameters are added:

• The Honest App generates a random string called code_verifier
• The Honest App computes the code_challenge=SHA-256(code_verifier)
• The Honest App specifies the challenge_method=SHA256

Step 2: The Authorization Server receives the Auth Request and binds the code to the received code_challenge and challenge_method.

• Later in Step 5, the Authorzation Server expects to receive the code_verifier. By comparing the SHA-256(code_verifier) value with the recieved code_challenge, the Authorization Server verifies that the sender of the Auth Request ist the same as the sender of the code.

Step 3-4: The code leaks again to the Evil App.

Step 5: Now, Evil App must send the code_verifier together with the code. Unfortunatelly, the App does not have it and is not able to compute it. Thus, it cannot redeem the code.

 PKCE Bypass via App Impersonation

Again, PKCE binds the Auth Request to the coderedemption.

The question rises, if an Evil App can build its own Auth Request with its own code_verifier, code_challenge and challenge_method.The short answer is – yes, it can.

Figure 3: Bypassing PKCE via the App Impersonation attack

Step 1: The Evil App generates an Auth Request. The Auth Request contains the client_id and redirect_uri of the Honest App. Thus, the User and the Authorization Server cannot recognize that the Evil App initiates this request. 

Step 2-4: These steps do not deviate from the previous description in Figure 2.

Step 5: In Step 5 the Evil App sends the code_verifier used for the computation of the code_challenge. Thus, the stolen code can be successfully redeemed and the Evil App receives the access_token and id_token.

OAuth 2.0 for Native Apps

The attack cannot be prevented by PKCE. However, the IETF working group is currently working on a Draft describing recommendations for using OAuth 2.0 for native apps.

References

[1] http://mews.sv.cmu.edu/papers/ccs-14.pdf

[2] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-06#section-8.1

[3] https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

Authors

Vladislav Mladenov
Christian Mainka (@CheariX)

Related posts

• Growth Hacking Barcelona
• Curso Hacking Etico Gratis
• Black Hacker
• Curso Growth Hacking

Read more...

BeEF: Browser Exploitation Framework

"BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of XSS browser vulnerabilities. Development has focused on creating a modular structure making new module development a trivial process with the intelligence residing within BeEF. Current modules include the first public Inter-protocol Exploit, a traditional browser overflow exploit, port scanning, keylogging, clipboard theft and more." read more...


Website: http://www.bindshell.net/tools/beef

Related links

• Curso Hacker
• Un Hacker
• Hacking System
• Cracker Informatico
• Hacking Time
• Hacker Blanco
• Hacking Growth Pdf
• Ethical Hacking Course
• Como Ser Un Buen Hacker

Read more...

Hacking Windows 95, Part 2

In the Hacking Windows 95, part 1 blog post, we covered that through a nasty bug affecting Windows 95/98/ME, the share password can be guessed in no time. In this article, I'm going to try to use this vulnerability to achieve remote code execution (with the help of publicly available tools only).

The first thing we can do when we have read access to the Windows directory through the share, is to locate all the *.pwl files on the c:\windows directory, copy them to your machine where Cain is installed, switch to Cracker tab, pwl files, load the pwl file, add username based on the filename, and try to crack it. If you can't crack it you might still try to add a .pwl file where you already know the password in the remote windows directory. Although this is a fun post-exploitation task, but still, no remote code execution. These passwords are useless without physical access.

One might think that after having a share password and user password, it is easy to achieve remote code execution. The problem is:

• there is no "at" command (available since Windows 95 plus!)
• there is no admin share
• there is no RPC
• there is no named pipes
• there is no remote registry
• there is no remote service management

If you think about security best practices, disabling unnecessary services is always the first task you should do. Because Windows 95 lacks all of these services, it is pretty much secure!

During my quest for a tool to hack Windows 95, I came across some pretty cool stuff:

Internet periscope

Winfingerprint

LanSpy

But the best of the best is Fluxay, which has been written by chinese hackers. It is the metasploit from the year 2000. A screenshot is worth more than a 1000 words. 4 screenshot > 4 thousand words :)

It is pretty hard to find the installer, but it is still out there!

But at the end, no remote code execution for me.

My idea here was that if I can find a file which executes regularly (on a scheduled basis), I can change that executable to my backdoor and I'm done. Although there is no scheduler in the default Windows 95, I gave it a try. 

Let's fire up taskman.exe to get an idea what processes are running:

Looks like we need a more powerful tool here, namely Process Explorer. Let's try to download this from oldapps.com:

LOL, IE3 hangs, can't render the page. Copying files to the Win95 VM is not that simple, because there are no shared folders in Win95 VM. And you can't use pendrives either, Win95 can't handle USB (at least the retail version). After downloading the application with a newer browser from oldapps, let's start Process Explorer on the test Windows 95.

Don't try to download the Winsocks 2 patch from the official MS site, it is not there anymore, but you can download it from other sites. 

Now let's look at the processes running:

After staring it for minutes, turned out it is constant, no new processes appeared.
Looking at the next screenshot, one can notice this OS was not running a lot of background processes ...

My current Win7 has 1181 threads and 84 processes running, no wonder it is slow as hell :)

We have at least the following options:

1. You are lucky and not the plain Windows 95 is installed, but Windows 95 Plus! The main difference here is that Windows 95 Plus! has built-in scheduler, especially the "at" command. Just overwrite a file which is scheduled to execution, and wait. Mission accomplished!
2. Ping of death - you can crash the machine (no BSOD, just crash) with long (over 65535 bytes) ICMP ping commands, and wait for someone to reboot it. Just don't forget to put your backdoor on the share and add it to autoexec.bat before crashing it. 
3. If your target is a plain Windows 95, I believe you are out of luck. No at command, no named pipes, no admin share, nothing. Meybe you can try to fuzz port 137 138 139, and write an exploit for those. Might be even Ping of Death is exploitable?

Let's do the first option, and hack Windows 95 plus!

Look at the cool features we have by installing Win95 Plus!

Cool new boot splash screen!

But our main interest is the new, scheduled tasks!

Now we can replace diskalm.exe with our backdoor executable, and wait maximum one hour to be scheduled.

Instead of a boring text based tutorial, I created a YouTube video for you. Based on the feedbacks on my previous tutorialz, it turned out I'm way too old, and can't do interesting tutorials. That's why I analyzed the cool skiddie videoz, and found that I have to do the followings so my vidz won't suck anymore:

• use cool black windows theme
• put meaningless performance monitor gadgets on the sidebar
• use a cool background, something related with hacking and skullz
• do as many opsec fails as possible
• instead of captions, use notepad with spelling errorz
• there is only one rule of metal: Play it fuckin' loud!!!!

Related news

• Hacking Web Technologies Pdf
• Hacking To The Gate
• Hacking Music
• Foro Hacking
• Hacker En Español
• Arduino Hacking

Read more...

PDFex: Major Security Flaws In PDF Encryption

After investigating the security of PDF signatures, we had a deeper look at PDF encryption. In co­ope­ra­ti­on with our friends from Müns­ter Uni­ver­si­ty of Ap­p­lied Sci­en­ces, we discovered severe weaknesses in the PDF encryption standard which lead to full plaintext exfiltration in an active-attacker scenario.

To guarantee confidentiality, PDF files can be encrypted. This enables the secure transfer and storing of sensitive documents without any further protection mechanisms.

The key management between the sender and recipient may be password based (the recipient must know the password used by the sender, or it must be transferred to them through a secure channel) or public key based (i.e., the sender knows the X.509 certificate of the recipient).

In this research, we analyze the security of encrypted PDF files and show how an attacker can exfiltrate the content without having the corresponding keys.

So what is the problem?

The security problems known as PDFex discovered by our research can be summarized as follows:

1. Even without knowing the corresponding password, the attacker possessing an encrypted PDF file can manipulate parts of it.
   More precisely, the PDF specification allows the mixing of ciphertexts with plaintexts. In combination with further PDF features which allow the loading of external resources via HTTP, the attacker can run direct exfiltration attacks once a victim opens the file.
2. PDF encryption uses the Cipher Block Chaining (CBC) encryption mode with no integrity checks, which implies ciphertext malleability.
   This allows us to create self-exfiltrating ciphertext parts using CBC malleability gadgets. We use this technique not only to modify existing plaintext but to construct entirely new encrypted objects.

Who uses PDF Encryption?

PDF encryption is widely used. Prominent companies like Canon and Samsung apply PDF encryption in document scanners to protect sensitive information.

Further providers like IBM offer PDF encryption services for PDF documents and other data (e.g., confidential images) by wrapping them into PDF. PDF encryption is also supported in different medical products to transfer health records, for example Innoport, Ricoh, Rimage.

Due to the shortcomings regarding the deployment and usability of S/MIME and OpenPGP email encryption, some organizations use special gateways to automatically encrypt email messages as encrypted PDF attachments, for example CipherMail, Encryptomatic, NoSpamProxy. The password to decrypt these PDFs can be transmitted over a second channel, such as a text message (i.e., SMS).

Technical details of the attacks

We developed two different attack classes on PDF Encryption: Direct Exfiltration and CBC Gadgets.

Attack 1: Direct Exfiltration (Attack A)

The idea of this attack is to abuse the partial encryption feature by modifying an encrypted PDF file. As soon as the file is opened and decrypted by the victim sensitive content is sent to the attacker. Encrpyted PDF files does not have integrity protection. Thus, an attacker can modify the structure of encrypted PDF documents, add unencrypted objects, or wrap encrypted parts into a context controlled the attacker.

In the given example, the attacker abuses the flexibility of the PDF encryption standard to define certain objects as unencrypted. The attacker modifies the Encrypt dictionary (6 0 obj) in a way that the document is partially encrypted – all streams are left AES256 encrypted while strings are defined as unencrypted by setting the Identity filter. Thus, the attacker can freely modify strings in the document and add additional objects containing unencrypted strings.

The content to be exfiltrated is left encrypted, see Contents (4 0 obj) and EmbeddedFile (5 0 obj). The most relevant object for the attack is the definition of an Action, which can submit a form, invoke a URL, or execute JavaScript. The Action references the encrypted parts as content to be included in requests and can thereby be used to exfiltrate their plaintext to an arbitrary URL. The execution of the Action can be triggered automatically once the PDF file is opened (after the decryption) or via user interaction, for example, by clicking within the document.

This attack has three requirements to be successful. While all requirements are PDF standard compliant, they have not necessarily been implemented by every PDF application:

• Partial encryption: Partially encrypted documents based on Crypt Filters like the Identity filter or based on other less supported methods like the None encryption algorithm.
• Cross-object references: It must be possible to reference and access encrypted string or stream objects from unencrypted attacker-controlled parts of the PDF document.
• Exfiltration channel: One of the interactive features allowing the PDF reader to communicate via Internet must exist, with or without user interaction. Such Features are PDF Forms, Hyperlinks, or JavaScript.

Please note that the attack does not abuse any cryptographic issues, so that there are no requirements to the underlying encryption algorithm (e.g., AES) or the encryption mode (e.g., CBC).

In the following, we show three techniques how an attack can exfiltrate the content.

Exfiltration via PDF Forms (A1)

The PDF standard allows a document's encrypted streams or strings to be defined as values of a PDF form to be submitted to an external server. This can be done by referencing their object numbers as the values of the form fields within the Catalog object, as shown in the example on the left side. The value of the PDF form points to the encrypted data stored in 2 0 obj.

To make the form auto-submit itself once the document is opened and decrypted, an OpenAction can be applied. Note that the object which contains the URL (http://p.df) for form submission is not encrypted and completely controlled by the attacker. As a result, as soon as the victim opens the PDF file and decrypts it, the OpenAction will be executed by sending the decrypted content of 2 0 obj to (http://p.df).

Exfiltration via Hyperlinks (A2)

If forms are not supported by the PDF viewer, there is a second method to achieve direct exfiltration of a plaintext. The PDF standard allows setting a "base" URI in the Catalog object used to resolve all relative URIs in the document.

This enables an attacker to define the encrypted part as a relative URI to be leaked to the attacker's web server. Therefore the base URI will be prepended to each URI called within the PDF file. In the given example, we set the base URI to (http://p.df).

The plaintext can be leaked by clicking on a visible element such as a link, or without user interaction by defining a URI Action to be automatically performed once the document is opened.

In the given example, we define the base URI within an Object Stream, which allows objects of arbitrary type to be embedded within a stream. This construct is a standard compliant method to put unencrypted and encrypted strings within the same document. Note that for this attack variant, only strings can be exfiltrated due to the specification, but not streams; (relative) URIs must be of type string. However, fortunately (from an attacker's point of view), all encrypted streams in a PDF document can be re-written and defined as hex-encoded strings using the hexadecimal string notation.

Nevertheless, the attack has some notable drawbacks compared to  Exfiltration via PDF Forms:

• The attack is not silent. While forms are usually submitted in the background (by the PDF viewer itself), to open hyperlinks, most applications launch an external web browser.
• Compared to HTTP POST, the length of HTTP GET requests, as invoked by hyperlinks, is limited to a certain size.
• PDF viewers do not necessarily URL-encode binary strings, making it difficult to leak compressed data.

Exfiltration via JavaScript (A3)

The PDF JavaScript reference allows JavaScript code within a PDF document to directly access arbitrary string/stream objects within the document and leak them with functions such as *getDataObjectContents* or *getAnnots*.

In the given example, the stream object 7 is given a Name (x), which is used to reference and leak it with a JavaScript action that is automatically triggered once the document is opened. The attack has some advantages compared to Exfiltration via PDF Forms and Exfiltration via Hyperlinks, such as the flexibility of an actual programming language.

It must, however, be noted that – while JavaScript actions are part of the PDF specification – various PDF applications have limited JavaScript support or disable it by default (e.g., Perfect PDF Reader).

Attack 2: CBC Gadgets (Attack B)

Not all PDF viewers support partially encrypted documents, which makes them immune to direct exfiltration attacks. However, because PDF encryption generally defines no authenticated encryption, attackers may use CBC gadgets to exfiltrate plaintext. The basic idea is to modify the plaintext data directly within an encrypted object, for example, by prefixing it with an URL. The CBC gadget attack, thus does not necessarily require cross-object references.

Note that all gadget-based attacks modify existing encrypted content or create new content from CBC gadgets. This is possible due to the malleability property of the CBC encryption mode.

This attack has two necessary preconditions:

• Known plaintext: To manipulate an encrypted object using CBC gadgets, a known plaintext segment is necessary. For AESV3 – the most recent encryption algorithm – this plain- text is always given by the Perms entry. For older versions, known plaintext from the object to be exfiltrated is necessary.
• Exfiltration channel: One of the interactive features: PDF Forms or Hyperlinks.

These requirements differ from those of the direct exfiltration attacks, because the attacks are applied "through" the encryption layer and not outside of it.

Exfiltration via PDF Forms (B1)

As described above, PDF allows the submission of string and stream objects to a web server. This can be used in conjunction with CBC gadgets to leak the plaintext to an attacker-controlled server, even if partial encryption is not allowed.

A CBC gadget constructed from the known plaintext can be used as the submission URL, as shown in the example on the left side. The construction of this particular URL gadget is challenging. As PDF encryption uses PKCS#5 padding, constructing the URL using a single gadget from the known Perms plaintext is difficult, as the last 4 bytes that would need to contain the padding are unknown.

However, we identified two techniques to solve this. On the one hand, we can take the last block of an unknown ciphertext and append it to our constructed URL, essentially reusing the correct PKCS#5 padding of the unknown plaintext. Unfortunately, this would introduce 20 bytes of random data from the gadgeting process and up to 15 bytes of the unknown plaintext to the end of our URL.

On the other hand, the PDF standard allows the execution of multiple OpenActions in a document, allowing us to essentially guess the last padding byte of the Perms value. This is possible by iterating over all 256 possible values of the last plaintext byte to get 0x01, resulting in a URL with as little random as possible (3 bytes). As a limitation, if one of the 3 random bytes contains special characters, the form submission URL might break.

Exfiltration via Hyperlinks (B2)

Using CBC gadgets, encrypted plaintext can be prefixed with one or more chosen plaintext blocks. An attacker can construct URLs in the encrypted PDF document that contain the plaintext to exfiltrate. This attack is similar to the exfiltration hyperlink attack (A2). However, it does not require the setting of a "base" URI in plaintext to achieve exfiltration.

The same limitations described for direct exfiltration based on links (A2) apply. Additionally, the constructed URL contains random bytes from the gadgeting process, which may prevent the exfiltration in some cases.

Exfiltration via Half-Open Object Streams (B3)

While CBC gadgets are generally restricted to the block size of the underlying block cipher – and more specifically the length of the known plaintext, in this case, 12 bytes – longer chosen plaintexts can be constructed using compression. Deflate compression, which is available as a filter for PDF streams, allows writing both uncompressed and compressed segments into the same stream. The compressed segments can reference back to the uncompressed segments and achieve the repetition of byte strings from these segments. These backreferences allow us to construct longer continuous plaintext blocks than CBC gadgets would typically allow for. Naturally, the first uncompressed occurrence of a byte string still appears in the decompressed result. Additionally, if the compressed stream is constructed using gadgets, each gadget generates 20 random bytes that appear in the decompressed stream. A non-trivial obstacle is to keep the PDF viewer from interpreting these fragments in the decompressed stream. While hiding the fragments in comments is possible, PDF comments are single-line and are thus susceptible to newline characters in the random bytes. Therefore, in reality, the length of constructed compressed plaintexts is limited.

To deal with this caveat, an attacker can use ObjectStreams which allow the storage of arbitrary objects inside a stream. The attacker uses an object stream to define new objects using CBC gadgets. An object stream always starts with a header of space-separated integers which define the object number and the byte offset of the object inside the stream. The dictionary of an object stream contains the key First which defines the byte offset of the first object inside the stream. An attacker can use this value to create a comment of arbitrary size by setting it to the first byte after their comment.

Using compression has the additional advantage that compressed, encrypted plaintexts from the original document can be embedded into the modified object. As PDF applications often create compressed streams, these can be incorporated into the attacker-created compressed object and will therefore be decompressed by the PDF applications. This is a significant advantage over leaking the compressed plaintexts without decompression as the compressed bytes are often not URL-encoded correctly (or at all) by the PDF applications, leading to incomplete or incomprehensible plaintexts. However, due to the inner workings of the deflate algorithms, a complete compressed plaintext can only be prefixed with new segments, but not postfixed. Therefore, a string created using this technique cannot be terminated using a closing bracket, leading to a half-open string. This is not a standard compliant construction, and PDF viewers should not accept it. However, a majority of PDF viewers accept it anyway.

Evaluation

During our security analysis, we identified two standard compliant attack classes which break the confidentiality of encrypted PDF files. Our evaluation shows that among 27 widely-used PDF viewers, all of them are vulnerable to at least one of those attacks, including popular software such as Adobe Acrobat, Foxit Reader, Evince, Okular, Chrome, and Firefox.

You can find the detailed results of our evaluation here.

What is the root cause of the problem?

First, many data formats allow to encrypt only parts of the content (e.g., XML, S/MIME, PDF). This encryption flexibility is difficult to handle and allows an attacker to include their own content, which can lead to exfiltration channels.

Second, when it comes to encryption, AES-CBC – or encryption without integrity protection in general – is still widely supported. Even the latest PDF 2.0 specification released in 2017 still relies on it. This must be fixed in future PDF specifications and any other format encryption standard, without enabling backward compatibility that would re-enable CBC gadgets.

A positive example is JSON Web Encryption standard, which learned from the CBC attacks on XML and does not support any encryption algorithm without integrity protection.

Authors of this Post

Jens Müller
Fabian Ising
Vladislav Mladenov
Christian Mainka
Sebastian Schinzel
Jörg Schwenk

Acknowledgements

Many thanks to the CERT-Bund team for the great support during the responsible disclosure process.Related news

1. Como Ser Un Buen Hacker
2. Curso Completo De Hacking Ético
3. Hacking Marketing
4. Start Hacking

Read more...